Phần còn lại ví dụ về api python

Đây là phần 23 và cũng là phần cuối của loạt bài này. Trong phần này, chúng ta sẽ tìm hiểu cách xây dựng giao diện lập trình ứng dụng [Application Programming Interface hay gọi tắt là API] cho ứng dụng của chúng ta để các ứng dụng khác có thể làm việc trực tiếp với Myblog mà không cần thiết

Để giúp các bạn dễ theo dõi, sau đây là danh sách các bài viết trong chuỗi bài hướng dẫn này

• Phần 1. Chào thế giới
• Phần 2. Tìm hiểu về mẫu
• Phần 3. Tìm hiểu về Web Forms
• Phần 4. Sử dụng cơ sở dữ liệu
• Phần 5. Xử lý đăng nhập
• Phần 6. Hồ sơ cá nhân và ảnh đại diện
• Phần 7. Xử lý lỗi
• Phần 8. Tạo chức năng theo dõi
• Phần 9. Partition
• Phần 10. Email hỗ trợ
• Phần 11. Nâng cấp giao diện
• Phần 12. Xử lý thời gian
• Phần 13. Hỗ trợ đa ngôn ngữ
• Phần 14. Sử dụng Ajax
• Phần 15. Tinh chỉnh cấu trúc ứng dụng
• Phần 16. Hỗ trợ tìm kiếm hỗ trợ
• Phần 17. Triển khai ứng dụng trên Linux
• Phần 18. Triển khai ứng dụng với Heroku
• Phần 19. Triển khai ứng dụng với Docker
• Phần 20. JavaScript nâng cao
• Phần 21. Thông báo cho người sử dụng
• Phần 22. Tìm hiểu về tác vụ nền
• Phần 23. Xây dựng API [Bài viết này]

Bạn có thể truy cập mã nguồn cho phần này tại GitHub

Cho đến thời điểm này, tất cả các chức năng mà chúng ta đã tạo ra trong ứng dụng chỉ có thể được sử dụng thông qua trình duyệt. Nhưng trong thực tế, một ứng dụng trên nền tảng Internet có thể được truy cập qua các chương trình khách [client] khác nhau. Ví dụ như nếu chúng ta muốn tạo ra một ứng dụng iOS hoặc Android sử dụng ứng dụng của chúng ta, chúng ta phải làm thế nào? Chúng ta có thể chọn một trong hai cách. Giải pháp dễ dàng nhất là tạo một ứng dụng đơn giản với một thành phần hiển thị Web [Web view] và kết nối với Web site có ứng dụng Myblog. Tuy nhiên, điều này không khác gì truy cập đến Myblog thông qua trình duyệt trên thiết bị. Một giải pháp tốt hơn nhiều [nhưng cũng tốn công hơn] là tạo ra một ứng dụng hoàn chỉnh. Nhưng điều này lại làm nảy sinh một vấn đề mới là làm sao để ứng dụng này có thể tương tác với máy chủ và ứng dụng chỉ trả về các trang HTML?

Để giải quyết vấn đề này, chúng ta có thể nhờ đến sự giúp đỡ của Giao diện lập trình ứng dụng [API]. Một API là một tập hợp các định tuyến HTTP được thiết kế như là các đầu mối xuất nhập ở mức thấp đến ứng dụng. Thay vì định nghĩa các định tuyến và các hàm hiển thị để trả về các trang HTML cho trình duyệt, các API cho phép các chương trình khách làm việc trực tiếp với các tài nguyên của ứng dụng và để cho các chương trình khách toàn quyền quyết định cách hiển thị các thông tin với người sử dụng.  Ví dụ như một API trong Myblog có thể cung cấp thông tin về user và bài viết cho chương trình khách hoặc cho phép user soạn thảo một bài viết có sẵn, nhưng ở mức dữ liệu và không pha trộn giữa dữ liệu và các logic về dữ liệu với HTML.  

Nếu bạn xem lại các định tuyến hiện có trong ứng dụng của chúng ta, bạn sẽ thấy một vài định tuyến phù hợp với định nghĩa về API như trên. Ví dụ như là các định tuyến trả về dữ liệu dạng JSON như là /translate trong Phần 14. Đây là một định tuyến với dữ liệu nhập là văn bản, ngôn ngữ nguồn và ngôn ngữ đích dưới dạng JSON và được gởi đến server bằng yêu cầu dạng POST. Yêu cầu này sẽ được server hồi đáp bằng văn bản được dịch cũng dưới dạng JSON. Server chỉ trả về dữ liệu được yêu cầu và giao trách nhiệm hiển thị dữ liệu này cho chương trình khách

Tuy nhiên, dù các định tuyến loại này trong ứng dụng nằm trong phạm trù của API, chúng được thiết kế để hỗ trợ cho ứng dụng qua trình duyệt. Các ứng dụng trong điện thoại di động vẫn không thể sử dụng các định tuyến này vì chúng yêu cầu người dùng phải đăng nhập và đăng nhập chỉ có thể được thực hiện thông qua một biểu mẫu HTML. Trong phần này, chúng ta sẽ thấy cách xây dựng các API không phụ thuộc vào trình duyệt và không đặt ra bất kỳ giới hạn nào cho các chương trình khách

Cho đến nay, vẫn chưa có định nghĩa tuyệt đối về cách xây dựng các API. There are the quan điểm trái ngược nhau trong vấn đề này. Một số người có thể không đồng ý khi chúng ta nói rằng định tuyến / bản dịch được cập nhật trên một API. Một số khác có thể đồng ý nhưng cho rằng đây là các API bị thiết yếu. Như vậy thì các API được thiết kế tốt có những tính năng đặc biệt gì?

You can have watching the REST API. REST [xuất phát từ thuật ngữ Chuyển giao trạng thái đại diện] là một kiến ​​trúc do tiến sĩ Dr. Roy Fielding đề cử trong cuộc tranh luận về tiến sĩ của ông. Trong luận án này, tiến sĩ Fielding đã giới thiệu sáu đặc tính tổng hợp định nghĩa về REST

Ngoài dự án của tiến sĩ Fielding, không có bất kỳ mô tả cụ thể nào khác để chuẩn hóa REST, vì vậy, nhiều chi tiết về cách xây dựng REST được diễn ra theo cách hiểu của giả giả. Chủ đề thảo luận về việc một API có phải là REST hay không thường là một chủ đề nóng và gây tranh cãi giữa những người theo REST “thuần túy” – là những người cho rằng các API REST phải có đủ sáu tính năng và khả năng chịu đựng . Về phần mình, tiến sĩ Fielding đứng về phía những người theo REST thuần túy và cung cấp thêm một số chi tiết về quan điểm của mình trong các bài viết và bình luận trên mạng.

Phần lớn các API REST đã được xây dựng hiện nay đi theo hướng “thực tế”, bao gồm tất cả các API từ các nhà phát triển lớn như Facebook, GitHub, Twitter,… Chỉ có một số rất ít API được công nhận là thành công . Và bất kể quan điểm nghiêm trọng của Tiến sĩ Fielding và cộng đồng REST “thuần tinh”, quan điểm về REST của giới phát triển phần mềm nói chung thiên về tính thực tế

Để giúp bạn có cái nhìn tổng quát trong luận án về REST của Tiến sĩ Fielding, chúng ta sẽ chỉ ra qua sáu nguyên tắc được đưa ra trong luận án

Chủ-Khách [Client-Server]

Nguyên tắc client-server tương đối rõ ràng. Nó chỉ nói rằng vai trò của máy khách và máy chủ phải được phân biệt rõ ràng trong một API REST. Khi áp dụng, điều này có nghĩa là máy khách và máy chủ phải ở trong các tiến trình [tiến trình] khác nhau và giao tiếp thông qua một kênh liên lạc – trong phần lớn trường hợp là giao thức HTTP qua mạng TCP

Hệ thống phân lớp [Layered System ]

Nguyên tắc hệ thống phân lớp định nghĩa rằng khi một khách hàng cần giao tiếp với một máy chủ, nó sẽ kết nối với một đối tượng trung gian và giao tiếp với đối tượng này thay vì máy chủ là sự thật. Trọng tâm ở đây là client không phân biệt giữa việc gửi yêu cầu đến máy chủ và một đối tượng trung gian, và thật ra, nó hoàn toàn không cần biết rằng nó đang kết nối với máy chủ là thật hay không. Và ở phía ngược lại, nguyên tắc này cũng đồng nghĩa với việc máy chủ có thể nhận các yêu cầu từ một đối tượng trung gian mà không phải trực tiếp từ máy khách. Do đó, máy chủ không được giả định rằng nó đang được kết nối với máy khách

Bộ nhớ tạm thời [Cache]

Nguyên tắc này cho phép máy chủ hoặc các đối tượng trung gian lưu câu trả lời cho các yêu cầu trùng lặp thường xuyên vào bộ nhớ tạm thời [cache] để rút ngắn thời gian phản hồi. Trong thực tế, phần lớn bạn đã gặp qua mô hình bộ đệm này trong các trình duyệt. Lớp cache trong trình duyệt thường được sử dụng để tránh việc gửi lại các yêu cầu đến cùng một tệp như các tệp hình ảnh trên cùng một máy chủ

Với các API, máy chủ cần phải chỉ định việc sử dụng chế độ điều khiển bộ đệm [cache control] nếu một câu trả lời phản hồi có thể được lưu vào bộ đệm bởi các đối tượng trung gian trước khi đến được máy khách. Lưu ý rằng vì lý do bảo mật, việc phát triển khai thác API trong môi trường sản phẩm phải được mã hóa. Do đó, việc sử dụng bộ đệm thường không được thực hiện ở các đối tượng trung gian, trừ khi các đối tượng này là điểm đầu cuối trong kết nối SSL hoặc thực hiện công việc mã hóa và giải mã

Mã theo yêu cầu [Code On Request]

Đây là một tùy chọn có nghĩa là máy chủ có thể cung cấp các mã có thể thực thi được cho khách hàng. Bởi vì nguyên tắc này yêu cầu máy chủ và máy khách đồng ý về loại mã nào có thể được thực thi bởi máy khách, nó khi được sử dụng trong các API. Bạn có thể cho rằng máy chủ có thể trả về mã JavaScript cho máy khách là trình duyệt có thể thi hành, nhưng REST không chỉ nhắm vào máy khách là trình duyệt. Vì vậy, việc thực thi JavaScript có thể gây ra một số rắc rối nếu khách hàng là thiết bị iOS hoặc Android

Không có trạng thái [Không trạng thái]

Nguyên tắc không có trạng thái là một trong hai nguyên tắc gây tranh cãi nhiều nhất giữa cộng đồng REST thuần túy và thực dụng. Nó định nghĩa rằng một API REST không nên lưu bất kỳ trạng thái nào của khách hàng để có thể được gọi lại mỗi khi khách hàng gửi một yêu cầu. Điều này có nghĩa là các kỹ thuật thông tin ứng dụng trong quá trình phát triển các ứng dụng Web để người dùng “ghi nhớ” khi họ tìm kiếm các trang khác nhau trong một phiên làm việc đều bất hợp lệ theo nguyên tắc này. Trong các API không có trạng thái, mỗi yêu cầu đều độc lập với nhau và phải kèm theo các thông tin cho phép máy chủ định danh, xác thực người dùng và hoàn tất công việc. Điều này cũng có nghĩa là máy chủ không thể lưu trữ bất kỳ dữ liệu nào liên quan đến kết nối từ máy khách trong cơ sở dữ liệu hoặc các hình thức lưu trữ khác

Nếu bạn thắc mắc tại sao máy chủ yêu cầu REST không phải là không có trạng thái, lý do chính là vì các máy chủ không có trạng thái có thể được mở rộng để phục vụ nhiều máy khách [quy mô] dễ dàng hơn. Để thực hiện việc mở rộng các máy chủ không ở trạng thái, bạn chỉ cần thực thi nhiều máy chủ cùng loại với một máy chủ cân bằng tải [load balancer] để phân phối các yêu cầu đến từng máy chủ. Nếu các máy chủ lưu trạng thái của máy khách, thì công việc này sẽ trở nên rất phức tạp vì bạn sẽ phải tìm cách để nhiều máy chủ có thể truy xuất và cập nhật các trạng thái này, hoặc phải đảm bảo rằng một máy khách sẽ luôn được xử lý

Nếu bạn xem xét lại định tuyến / dịch mà chúng tôi đã đề cập đến phần trên, bạn sẽ thấy rằng nó không phù hợp với tiêu chuẩn của REST bởi vì chức năng hiển thị của tuyến này có sử dụng trang trí @login_required của thư viện Flask

Giao diện đồng nhất [Uniform Interface]

Nguyên tắc cuối cùng, cũng là nguyên tắc gây tranh cãi và nhập nhằng nhất trong các tài liệu về REST là nguyên tắc giao diện đồng nhất. Tiến sĩ Fielding liệt kê các khía cạnh phân biệt của nguyên tắc này là. định danh tài nguyên duy nhất [mã định danh tài nguyên duy nhất], đặc tả tài nguyên [đại diện tài nguyên], thông điệp tự mô tả [tự mô tả] và các siêu phương tiện [hypermedia]

Định danh tài nguyên duy nhất được thực hiện bằng cách gán các URL duy nhất cho mỗi tài nguyên. Ví dụ như một URL liên kết với một user có thể là /api/users/ với là định danh được gán cho user đó trong khóa chính của bản tương ứng trong cơ sở dữ liệu. Điều này được xây dựng trong hầu hết các API.

Việc sử dụng các đặc tả tài nguyên có nghĩa là khi máy chủ và máy khách trao đổi thông tin về một tài nguyên, chúng phải sử dụng một định dạng chung được chấp nhận từ cả hai phía. Với hầu hết các API hiện đại, định dạng JSON được sử dụng cho mục đích này. Một API cũng có thể hỗ trợ nhiều đặc tả tài nguyên khác nhau cùng lúc, và trong những trường hợp như vậy, các tùy chọn để thỏa thuận về nội dung [thương lượng nội dung] trong giao thức HTTP sẽ được máy chủ và máy khách sử dụng để sử dụng.

Các thông báo tự mô tả có nghĩa là các yêu cầu và câu trả lời phản hồi giữa máy khách và máy chủ phải có tất cả các thông tin mà đối tác cần. Một ví dụ điển hình là phương thức yêu cầu HTTP được sử dụng để chỉ định loại nhiệm vụ mà máy khách muốn máy chủ thực thi. Một yêu cầu GET chỉ ra rằng khách hàng muốn lấy thông tin về một tài nguyên, một yêu cầu POST chỉ ra rằng khách hàng muốn tạo ra một tài nguyên mới, PUT hoặc PATCH định nghĩa các yêu cầu để cập nhật các tài nguyên hiện có, . Đích tài nguyên sẽ được chỉ định trong URL của yêu cầu và với các thông tin bổ sung nằm trong mục đầu của HTTP yêu cầu, một phần trong danh sách tham số trong URL [chuỗi truy vấn] hoặc trong phần thân của yêu cầu HTTP

Tiêu chuẩn về siêu phương tiện là tiêu chuẩn gây ra nhiều tranh cãi nhất và chỉ được một số ít giám sát API theo, và ngay cả các API giám sát theo đặc tả này cũng không được xây dựng theo cách thức làm hài lòng cộng đồng “ . Bởi vì các tài nguyên trong một ứng dụng đều liên quan với nhau, tiêu chuẩn này yêu cầu các liên hệ này phải được đưa vào trong các đặc tả tài nguyên để khách hàng có thể tự tìm kiếm các tài nguyên mới bằng cách một lần . Trọng tâm của tiêu chuẩn này là cho phép khách hàng sử dụng API mà không biết trước về các tài nguyên được API này sử dụng, nhưng có thể tìm ra các tài nguyên này bằng cách một lần theo các siêu liên kết. Tuy nhiên, tiêu chuẩn này lại gặp rắc rối khi xây dựng vì định dạng JSON vốn rất phổ biến để sử dụng cho mục đích đặc tả tài nguyên trong các API lại không có cách chuẩn để khai báo các liên kết như HTML hoặc XML. Vì vậy, bạn buộc phải sử dụng một tùy chọn cấu trúc hoặc một biến trong các tiêu chuẩn mở rộng của JSON để lấp đầy khoảng trống này như JSON-API, HAL, JSON-LD hoặc các tiêu chuẩn tương tự

Để giúp bạn có một khái niệm về việc phát triển các API, chúng ta sẽ thêm một API vào ứng dụng Myblog. API này sẽ không phải là một API hoàn chỉnh, chúng ta sẽ xây dựng tất cả các chức năng liên quan đến người sử dụng nhưng rút lại các chức năng liên quan đến các tài nguyên khác như là bài viết để bạn có thể thực hiện

Để tuân theo cấu trúc của ứng dụng mà chúng tôi đã đưa ra trong Phần 15, chúng tôi sẽ tạo ra một kế hoạch chi tiết có chứa tất cả các tuyến đường của API. Chúng ta sẽ bắt đầu công việc tạo ra một thư mục cho kế hoạch chi tiết mới

1

[myenv] $ mkdir app/api

Tệp __init__. py sẽ tạo ra các đối tượng tương ứng cho bản thiết kế tương tự như các bản thiết kế khác trong ứng dụng

ứng dụng/__init__. py. Constructor for blueprint of API

1

2

3

4

5

từ bình nhập Bản thiết kế

bp = Kế hoạch chi tiết['api'