Tweet
REST API và Phân trang
Một phần quan trọng trong đặc tả REST là phản hồi cần bao gồm các siêu liên kết (hyperlink) đến các tài nguyên liên quan khác. Điều này rất hữu ích vì phía client chỉ cần một điểm cuối (endpoint), thậm chí có thể không biết trước những gì sẽ nhận được. Nhờ phương pháp này, phản hồi trở nên rất hữu ích cho client.
Có một từ viết tắt cho điều này – HATEOAS (Hypermedia As The Engine Of Application State – Siêu phương tiện là động cơ của trạng thái ứng dụng). Bằng cách cung cấp các liên kết siêu phương tiện, có thể trỏ đến văn bản siêu liên kết, đa phương tiện, hoặc bất kỳ nội dung nào được lưu trữ ở phía bên kia, bạn đang giúp client khám phá các tài nguyên. Nhờ đó, client có thể lấy được mọi thứ cần thiết.
Ví dụ, nếu bạn kết nối với bảng điều khiển của một ứng dụng đám mây, chẳng hạn như Meraki, trước tiên bạn cần kết nối với điểm cuối REST API. Bạn cần xác thực. Thông thường, việc đầu tiên bạn muốn làm là liệt kê các mạng (networks). Khi liệt kê các mạng, bạn sẽ nhận được các liên kết đến tất cả các mạng đó. Sau đó, bạn có thể theo dõi từng liên kết, áp dụng cách tiếp cận từ trên xuống (top-down).
Chẳng hạn, chúng ta có một phản hồi như sau: Client đầu tiên kết nối đến /item, nhận được danh sách tất cả các mục với các ID. Sau đó, với mỗi ID, có các liên kết bổ sung – ví dụ, liên kết để thêm mục đó vào giỏ hàng (shopping cart) hoặc danh sách mong muốn (wish list). Khi mục đã ở trong giỏ hàng, nó có thể được đặt hàng hoặc xóa khỏi giỏ hàng.
Client không cần biết trước các cách thức khả thi, các đối tượng là gì, hay cách truy cập chúng. Tất cả thông tin này được bao gồm trong phản hồi từ điểm cuối API. Vậy server có thể trả về thông tin này như thế nào? Có nhiều cách để thực hiện. Một trong số đó là sử dụng tiêu chuẩn HTTP, cụ thể là RFC (Request for Comments) về liên kết web.
Trong thông tin metadata của các tiêu đề HTTP (HTTP headers) được server trả về, có thể chứa một tiêu đề với các liên kết bổ sung đến các tài nguyên liên quan. Ví dụ, nếu đây là danh sách các mặt hàng có thể mua trong cửa hàng, bạn có thể nhận được các liên kết cho trang trước, trang tiếp theo, trang đầu tiên, hoặc trang cuối cùng. Điều này giúp client hiển thị thanh điều hướng cho người dùng cuối.
Điểm mạnh của phương pháp này là nó có thể được thực hiện một cách động. Client không cần biết nhiều về cấu trúc dữ liệu. Nó chỉ cần biết địa chỉ điểm cuối và có quyền xác thực. Từ đó, mọi thứ được thực hiện động dựa trên quyền mà client sở hữu. Đây là một cách, sử dụng tiêu đề liên kết HTTP (HTTP link header).
Ngoài ra, thông tin này cũng có thể được đưa vào phần payload của phản hồi. Ở đây, bạn có thể thấy một ví dụ định dạng JSON. Bạn nhận được metadata, bao gồm số lượng bản ghi (record count), số lượng trang (page count), số lượng kết quả được gửi trên mỗi trang. Bạn cũng nhận được các liên kết, như cách bắt đầu với danh sách kết quả, trang trước, trang tiếp theo, trang cuối cùng. Điều này giúp client dễ dàng cung cấp quyền truy cập dữ liệu cho người dùng. Và tất nhiên, có danh sách các mục như thường lệ. Thông tin metadata này thực sự rất hữu ích.
Nhờ đó, trải nghiệm người dùng cuối được cải thiện đáng kể. Bạn tiết kiệm tài nguyên, giảm thời gian phản hồi. Nhìn chung, đây là một trong những phương pháp tốt nhất để làm cho ứng dụng của bạn hiệu quả hơn và hữu ích trong dài hạn.
Phân trang trong REST API
Khi client yêu cầu một tài nguyên từ REST API, phản hồi có thể là một tập dữ liệu rất lớn. Thường thì toàn bộ dữ liệu không liên quan đến client, và client chỉ quan tâm đến một phần cụ thể của phản hồi. Ví dụ, người dùng có thể chỉ muốn lấy một số thông báo nhật ký máy chủ (server log messages) được tạo trong một khoảng thời gian cụ thể. Phân trang là một phương pháp để xử lý các tập dữ liệu lớn, cung cấp cách chia nhỏ dữ liệu để cả client và server có thể xử lý các yêu cầu dễ dàng hơn. Một REST API được thiết kế tốt nên triển khai phân trang để tối ưu hóa trải nghiệm người dùng và tiết kiệm tài nguyên ở phía client, server và quá trình truyền tải.
Phân trang là một khái niệm quen thuộc trong web dựa trên trình duyệt. Ví dụ, khi bạn tìm kiếm “REST API” trên một công cụ tìm kiếm, bạn nhận được hàng nghìn kết quả trang web. Trình duyệt không thể hiển thị tất cả kết quả trên cùng một trang, và công cụ tìm kiếm cũng sẽ cần nhiều tài nguyên để cung cấp nội dung mà có thể không hữu ích cho bạn. Đó là lý do tại sao công cụ tìm kiếm hiển thị một thanh phân trang, cho phép bạn điều hướng qua các kết quả tìm kiếm, chỉ hiển thị một lượng thông tin giới hạn và thực hiện tìm kiếm mới mỗi khi bạn nhấp vào một liên kết trang.
Nguyên tắc tương tự được áp dụng cho REST API. Các lý do chính để sử dụng phân trang trong REST API bao gồm:
Một phần quan trọng trong đặc tả REST là phản hồi cần bao gồm các siêu liên kết (hyperlink) đến các tài nguyên liên quan khác. Điều này rất hữu ích vì phía client chỉ cần một điểm cuối (endpoint), thậm chí có thể không biết trước những gì sẽ nhận được. Nhờ phương pháp này, phản hồi trở nên rất hữu ích cho client.
Có một từ viết tắt cho điều này – HATEOAS (Hypermedia As The Engine Of Application State – Siêu phương tiện là động cơ của trạng thái ứng dụng). Bằng cách cung cấp các liên kết siêu phương tiện, có thể trỏ đến văn bản siêu liên kết, đa phương tiện, hoặc bất kỳ nội dung nào được lưu trữ ở phía bên kia, bạn đang giúp client khám phá các tài nguyên. Nhờ đó, client có thể lấy được mọi thứ cần thiết.
Ví dụ, nếu bạn kết nối với bảng điều khiển của một ứng dụng đám mây, chẳng hạn như Meraki, trước tiên bạn cần kết nối với điểm cuối REST API. Bạn cần xác thực. Thông thường, việc đầu tiên bạn muốn làm là liệt kê các mạng (networks). Khi liệt kê các mạng, bạn sẽ nhận được các liên kết đến tất cả các mạng đó. Sau đó, bạn có thể theo dõi từng liên kết, áp dụng cách tiếp cận từ trên xuống (top-down).
Chẳng hạn, chúng ta có một phản hồi như sau: Client đầu tiên kết nối đến /item, nhận được danh sách tất cả các mục với các ID. Sau đó, với mỗi ID, có các liên kết bổ sung – ví dụ, liên kết để thêm mục đó vào giỏ hàng (shopping cart) hoặc danh sách mong muốn (wish list). Khi mục đã ở trong giỏ hàng, nó có thể được đặt hàng hoặc xóa khỏi giỏ hàng.
Client không cần biết trước các cách thức khả thi, các đối tượng là gì, hay cách truy cập chúng. Tất cả thông tin này được bao gồm trong phản hồi từ điểm cuối API. Vậy server có thể trả về thông tin này như thế nào? Có nhiều cách để thực hiện. Một trong số đó là sử dụng tiêu chuẩn HTTP, cụ thể là RFC (Request for Comments) về liên kết web.
Trong thông tin metadata của các tiêu đề HTTP (HTTP headers) được server trả về, có thể chứa một tiêu đề với các liên kết bổ sung đến các tài nguyên liên quan. Ví dụ, nếu đây là danh sách các mặt hàng có thể mua trong cửa hàng, bạn có thể nhận được các liên kết cho trang trước, trang tiếp theo, trang đầu tiên, hoặc trang cuối cùng. Điều này giúp client hiển thị thanh điều hướng cho người dùng cuối.
Điểm mạnh của phương pháp này là nó có thể được thực hiện một cách động. Client không cần biết nhiều về cấu trúc dữ liệu. Nó chỉ cần biết địa chỉ điểm cuối và có quyền xác thực. Từ đó, mọi thứ được thực hiện động dựa trên quyền mà client sở hữu. Đây là một cách, sử dụng tiêu đề liên kết HTTP (HTTP link header).
Ngoài ra, thông tin này cũng có thể được đưa vào phần payload của phản hồi. Ở đây, bạn có thể thấy một ví dụ định dạng JSON. Bạn nhận được metadata, bao gồm số lượng bản ghi (record count), số lượng trang (page count), số lượng kết quả được gửi trên mỗi trang. Bạn cũng nhận được các liên kết, như cách bắt đầu với danh sách kết quả, trang trước, trang tiếp theo, trang cuối cùng. Điều này giúp client dễ dàng cung cấp quyền truy cập dữ liệu cho người dùng. Và tất nhiên, có danh sách các mục như thường lệ. Thông tin metadata này thực sự rất hữu ích.
Nhờ đó, trải nghiệm người dùng cuối được cải thiện đáng kể. Bạn tiết kiệm tài nguyên, giảm thời gian phản hồi. Nhìn chung, đây là một trong những phương pháp tốt nhất để làm cho ứng dụng của bạn hiệu quả hơn và hữu ích trong dài hạn.
Phân trang trong REST API
Khi client yêu cầu một tài nguyên từ REST API, phản hồi có thể là một tập dữ liệu rất lớn. Thường thì toàn bộ dữ liệu không liên quan đến client, và client chỉ quan tâm đến một phần cụ thể của phản hồi. Ví dụ, người dùng có thể chỉ muốn lấy một số thông báo nhật ký máy chủ (server log messages) được tạo trong một khoảng thời gian cụ thể. Phân trang là một phương pháp để xử lý các tập dữ liệu lớn, cung cấp cách chia nhỏ dữ liệu để cả client và server có thể xử lý các yêu cầu dễ dàng hơn. Một REST API được thiết kế tốt nên triển khai phân trang để tối ưu hóa trải nghiệm người dùng và tiết kiệm tài nguyên ở phía client, server và quá trình truyền tải.
Phân trang là một khái niệm quen thuộc trong web dựa trên trình duyệt. Ví dụ, khi bạn tìm kiếm “REST API” trên một công cụ tìm kiếm, bạn nhận được hàng nghìn kết quả trang web. Trình duyệt không thể hiển thị tất cả kết quả trên cùng một trang, và công cụ tìm kiếm cũng sẽ cần nhiều tài nguyên để cung cấp nội dung mà có thể không hữu ích cho bạn. Đó là lý do tại sao công cụ tìm kiếm hiển thị một thanh phân trang, cho phép bạn điều hướng qua các kết quả tìm kiếm, chỉ hiển thị một lượng thông tin giới hạn và thực hiện tìm kiếm mới mỗi khi bạn nhấp vào một liên kết trang.
Nguyên tắc tương tự được áp dụng cho REST API. Các lý do chính để sử dụng phân trang trong REST API bao gồm:
- Tiết kiệm tài nguyên: Cung cấp các phản hồi lớn đòi hỏi nhiều tài nguyên tính toán và mạng.
- Cải thiện thời gian phản hồi: Vì các phản hồi phân trang nhỏ hơn nhiều, chúng có thể được xử lý nhanh hơn bởi server và mạng.
- Nâng cao trải nghiệm người dùng cuối: Phản hồi nhanh hơn mang lại trải nghiệm tốt hơn. Thông tin liên quan có thể được lấy dễ dàng hơn mà không cần phân tích tập dữ liệu lớn, và phản hồi có thể được tùy chỉnh cho các ứng dụng client khác nhau.