Tôi không hiểu lợi ích của HATEOAS đối với các API dành cho các chương trình sử dụng (trái ngược với con người trực tiếp duyệt API của bạn). Chắc chắn, khách hàng không bị ràng buộc với một lược đồ URL nhưng họ bị ràng buộc với một lược đồ dữ liệu giống với suy nghĩ của tôi.
Ví dụ: giả sử tôi muốn xem một mục trên đơn hàng, giả sử tôi đã phát hiện hoặc biết URL đơn hàng.
NGÀY:
order = get(orderURL);
item = get(order.itemURL[5]);
không phải HATEOAS:
order = get(orderURL);
item = get(getItemURL(order,5));
Trong mô hình đầu tiên tôi phải biết thực tế là đối tượng đặt hàng có trường itemURL. Trong mô hình thứ hai, tôi phải biết cách tạo một URL mục. Trong cả hai trường hợp, tôi phải "biết" điều gì đó trước thời hạn, vậy HATEOAS thực sự đang làm gì cho tôi?
Khi bạn viết ứng dụng khách, bạn phải biết trước trường đó là gì.
—
Pace
Không, đó là điểm chính của HATEOAS, bạn không cần phải biết trước lĩnh vực này là gì, bạn chỉ cần một vài điểm tiêu chuẩn và phần còn lại có thể khám phá được. "Nguyên tắc là máy khách tương tác hoàn toàn với ứng dụng mạng thông qua hypermedia được cung cấp động bởi các máy chủ ứng dụng. Máy khách REST không cần biết trước về cách tương tác với bất kỳ ứng dụng hoặc máy chủ cụ thể nào ngoài sự hiểu biết chung về hypermedia."
—
yannis
Làm thế nào để một ứng dụng có được món hàng từ một đơn đặt hàng nếu ứng dụng thậm chí không biết một đơn hàng có một món hàng? Discovery hoạt động để duyệt thủ công nhưng không phải cho các ứng dụng tự động.
—
Pace
Bản thân người đàn ông nói về nó ở đây: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
—
Thiago Silva
get(orderURL);nên nói cho bạnthe fact that the order object has an itemURL field.