Một lượng lớn những gì tôi nghĩ rằng tôi biết về REST rõ ràng là sai - và tôi không đơn độc. Câu hỏi này có một sự dẫn dắt dài dòng, nhưng có vẻ là cần thiết vì thông tin hơi tản mạn. Câu hỏi thực sự đến ở phần cuối nếu bạn đã quen thuộc với chủ đề này.
Từ đoạn đầu tiên của các API REST của Roy Fielding phải theo hướng siêu văn bản , rõ ràng là anh ấy tin rằng công việc của mình đang bị hiểu sai rộng rãi:
Tôi đang cảm thấy thất vọng bởi số lượng người gọi bất kỳ giao diện dựa trên HTTP nào là API REST. Ví dụ hôm nay là API REST SocialSite . Đó là RPC. Nó hét lên RPC. Có rất nhiều khớp nối trên màn hình nên được xếp hạng X.
Fielding tiếp tục liệt kê một số thuộc tính của API REST. Một số người trong số họ dường như đi ngược lại với cả thông lệ và lời khuyên thông thường trên SO và các diễn đàn khác. Ví dụ:
Một API REST phải được nhập mà không có kiến thức trước ngoài URI ban đầu (dấu trang) và tập hợp các loại phương tiện được tiêu chuẩn hóa phù hợp với đối tượng dự kiến (tức là bất kỳ khách hàng nào có thể sử dụng API đều mong đợi hiểu được). ...
API REST không được xác định tên tài nguyên cố định hoặc cấu trúc phân cấp (một sự kết hợp rõ ràng giữa máy khách và máy chủ). ...
API REST nên dành gần như toàn bộ nỗ lực mô tả của mình trong việc xác định (các) loại phương tiện được sử dụng để đại diện cho tài nguyên và thúc đẩy trạng thái ứng dụng hoặc trong việc xác định tên quan hệ mở rộng và / hoặc đánh dấu hỗ trợ siêu văn bản cho các loại phương tiện tiêu chuẩn hiện có. ...
Ý tưởng về "siêu văn bản" đóng một vai trò trung tâm - hơn nhiều so với cấu trúc URI hoặc ý nghĩa của động từ HTTP. "Siêu văn bản" được định nghĩa trong một trong các nhận xét:
Khi tôi [Fielding] nói siêu văn bản, ý tôi là việc trình bày đồng thời thông tin và kiểm soát sao cho thông tin trở thành khả năng chi trả mà thông qua đó người dùng (hoặc automaton) có được các lựa chọn và lựa chọn hành động. Hypermedia chỉ là một bản mở rộng về ý nghĩa của văn bản để bao gồm các neo tạm thời trong một luồng phương tiện; hầu hết các nhà nghiên cứu đã bỏ sự khác biệt.
Siêu văn bản không cần phải là HTML trên trình duyệt. Máy có thể đi theo các liên kết khi chúng hiểu định dạng dữ liệu và các kiểu quan hệ.
Tôi đang đoán vào thời điểm này, nhưng hai điểm đầu tiên ở trên dường như gợi ý rằng tài liệu API cho tài nguyên Foo trông giống như phần sau dẫn đến sự kết hợp chặt chẽ giữa máy khách và máy chủ và không có vị trí trong hệ thống RESTful.
GET /foos/{id} # read a Foo
POST /foos/{id} # create a Foo
PUT /foos/{id} # update a Foo
Thay vào đó, một đại lý phải bị buộc phải phát hiện ra các URI cho tất cả các Foos, ví dụ: đưa ra yêu cầu GET đối với / foos. (Các URI đó có thể tuân theo mô hình ở trên, nhưng đó là điều bên cạnh vấn đề.) Phản hồi sử dụng một loại phương tiện có khả năng truyền đạt cách truy cập từng mục và những gì có thể được thực hiện với nó, dẫn đến điểm thứ ba ở trên . Vì lý do này, tài liệu API nên tập trung vào việc giải thích cách diễn giải siêu văn bản có trong phản hồi.
Hơn nữa, mỗi khi URI tới tài nguyên Foo được yêu cầu, phản hồi chứa tất cả thông tin cần thiết để tác nhân khám phá cách tiến hành, ví dụ: truy cập các tài nguyên mẹ và liên kết thông qua URI của chúng hoặc bằng cách thực hiện hành động sau khi tạo / xóa tài nguyên.
Chìa khóa của toàn bộ hệ thống là phản hồi bao gồm siêu văn bản chứa trong một loại phương tiện mà chính nó chuyển tải đến các tùy chọn tác nhân để tiếp tục. Nó không giống như cách một trình duyệt hoạt động cho con người.
Nhưng đây chỉ là dự đoán tốt nhất của tôi tại thời điểm cụ thể này.
Fielding đã đăng một bài tiếp theo, trong đó anh ta đáp lại những lời chỉ trích rằng cuộc thảo luận của anh ta quá trừu tượng, thiếu ví dụ và giàu biệt ngữ:
Những người khác sẽ cố gắng giải mã những gì tôi đã viết theo những cách trực tiếp hơn hoặc có thể áp dụng cho một số mối quan tâm thực tế ngày nay. Có lẽ tôi sẽ không làm, bởi vì tôi quá bận rộn với chủ đề tiếp theo, chuẩn bị cho một hội nghị, viết một tiêu chuẩn khác, đi du lịch đến một nơi xa xôi nào đó, hoặc chỉ làm những việc nhỏ để tôi cảm thấy mình đã kiếm được tiền lương.
Vì vậy, hai câu hỏi đơn giản dành cho các chuyên gia REST có tư duy thực tế: làm thế nào để bạn giải thích những gì Fielding đang nói và làm thế nào để bạn áp dụng nó vào thực tế khi lập tài liệu / triển khai các API REST?
Chỉnh sửa: câu hỏi này là một ví dụ về việc khó học một thứ gì đó nếu bạn không có tên cho thứ bạn đang nói. Tên trong trường hợp này là "Hypermedia as the Engine of Application State" (HATEOAS).