Các ví dụ thực tế cho HATEOAS (REST-architecture) [đã đóng]

như mọi người có thể nhận thấy, có rất nhiều API REST giả / thô sơ trong tự nhiên (thực thi API HTTP và gọi nó là REST mà không tuân theo yêu cầu trạng thái siêu văn bản của ứng dụng, dẫn đến với câu chuyện nổi tiếng của Roy T. Fielding , người đầu tiên chỉ định mô hình REST).

Tôi đã không thể tìm thấy bất kỳ ví dụ thực tế nào về việc triển khai REST được điều khiển siêu văn bản thực sự cùng với các định nghĩa loại phương tiện dành riêng cho ứng dụng liên quan cho các chuyển đổi trạng thái.

Có bất kỳ ví dụ có thể truy cập công khai của việc thực hiện như vậy?

Đây không phải là một triển khai theo nghĩa chạy mã, nhưng tôi thực sự thích bài viết " Cách lấy một tách cà phê " trên InfoQ. Nó mô tả quá trình đặt hàng cà phê tại Starbucks dưới dạng giao thức RESTful. Điều này vượt xa bài viết giới thiệu REST "mọi thứ là một tài nguyên" điển hình và tập trung vào HATEOAS. Rất khuyến khích.

Làm thế nào về API Sun Cloud ? Từ phần giới thiệu:

API giả định không có cấu trúc cụ thể trong không gian URI. Điểm bắt đầu là một URI, được cung cấp bởi nhà cung cấp dịch vụ đám mây, xác định chính đám mây. Đại diện của đám mây chứa URI cho các tài nguyên khác trong đám mây và cũng cho các hoạt động có thể được thực hiện trên chúng (ví dụ: triển khai và khởi động máy ảo).

Các cốt truyện cũng có thể hữu ích.

Netflix có API REST dựa trên HATEOAS bao gồm các liên kết như một phần của tài nguyên.

Không phải RESTfulness của Sun Cloud API thực sự được đề cập ở điểm thứ 4 của Roy:

API REST không được xác định tên tài nguyên hoặc cấu trúc phân cấp cố định (khớp nối rõ ràng giữa máy khách và máy chủ). Máy chủ phải có quyền tự do kiểm soát không gian tên của chính họ. Thay vào đó, cho phép các máy chủ hướng dẫn khách hàng cách xây dựng các URI phù hợp, chẳng hạn như được thực hiện trong các biểu mẫu HTML và mẫu URI, bằng cách xác định các hướng dẫn đó trong các loại phương tiện và quan hệ liên kết. [Thất bại ở đây ngụ ý rằng các máy khách đang giả định cấu trúc tài nguyên do thông tin ngoài băng, chẳng hạn như tiêu chuẩn dành riêng cho miền, là hướng dữ liệu tương đương với khớp nối chức năng của RPC].

Ví dụ 1 Tên tài nguyên cố định trong một người thừa kế được xác định:

Từ API của Sun Cloud: "... đại diện của VDC sẽ bao gồm các đại diện của các Cụm cư trú trong đó, lần lượt bao gồm các đại diện của VM trong mỗi cụm."

Ví dụ 2 thông tin ngoài băng, chẳng hạn như tiêu chuẩn dành riêng cho tên miền:

Bạn phải có nội dung trang wiki (thông tin ngoài băng tần) để biết rằng "cơ chế truyền thông tài nguyên" cho trường tài nguyên đám mây "uri" là GET.

Tôi nhận ra điều này đã được hỏi cách đây một thời gian, nhưng tôi đã cố gắng thể hiện luồng API REST "phù hợp" cho một ví dụ đơn giản. Tôi đã cố tuân theo các quy tắc của Roy cho REST - có lẽ nó có thể giúp: Ví dụ API sử dụng REST