REST và URI Caching

Question

Như tôi đã hiểu, sử dụng dịch vụ Web RESTful hypertext-driven, một khách hàng không được biết bất cứ điều gì về bố cục máy chủ URI ngoại trừ một vài điểm vào nổi tiếng. Điều này được cho phép để cho phép máy chủ kiểm soát không gian URI của chính nó và giảm khớp nối với máy khách.

Khi khách hàng cho dịch vụ gửi yêu cầu thành công để tạo tài nguyên mới, dịch vụ trả lời 201 CREATED và cung cấp cho URI tài nguyên mới có thể truy cập trong trường Tiêu đề vị trí.

Khách hàng có được phép lưu trữ URI này để cho phép truy cập trực tiếp vào tài nguyên trong tương lai và nếu như vậy trong bao lâu? Nếu các URI được lưu trữ bởi máy khách, điều này dường như đang thiết lập một tình huống trong đó mỗi lần máy chủ thay đổi bố cục URI của nó, nó sẽ cần đảm bảo chuyển hướng vĩnh viễn được phục vụ khi các URI cũ được truy cập. Nếu không, khách hàng sẽ bị hỏng. Trong vài năm, hệ thống chuyển hướng này có thể bị mất.

Tình trạng này dường như không cho phép máy chủ kiểm soát nhiều hơn không gian URI của nó so với phương pháp lai REST-RPC sử dụng mẫu URI.

Có rất nhiều thông tin có sẵn về cách trình bày bộ nhớ đệm, nhưng về URI bộ nhớ đệm trong hệ thống RESTful theo hướng siêu văn bản thì sao?

Answer 1

Hãy nhớ rằng Tim Berners-Lee cho biết, "URL tuyệt vời không thay đổi". Khi máy chủ đưa ra một URI cho máy khách, bây giờ nó là công việc của máy chủ để giữ cho URI hoạt động trong tương lai bằng (ví dụ) gửi một phản hồi di chuyển vĩnh viễn trong trường hợp URI thay đổi và ai đó yêu cầu một URI cũ. Đây thực sự là những gì khuyến khích nhiều người thiết kế URI mờ, như dựa trên id cơ sở dữ liệu hoặc dấu thời gian, thay vì sử dụng một số thuộc tính có thể đọc được của con người của tài nguyên trong URI. Bất cứ điều gì mà mọi người hiểu, họ sẽ muốn thay đổi.

Answer 2

Vì một trong các nguyên tắc của REST là tài nguyên là địa chỉ, có vẻ như hoàn toàn chấp nhận được đối với khách hàng để theo dõi địa chỉ (URI) cho một tài nguyên nhất định. URI tài nguyên phải là một trong những "điểm vào nổi tiếng" mà bạn đã đề cập đến.

Answer 3

Có khách hàng phải được phép lưu trữ URI. Miễn là nó muốn. Như Licky đề cập đến một khách hàng thông minh có thể sử dụng một Moved-Vĩnh viễn phản ứng để cập nhật đánh dấu của nó.

Nếu bạn nghĩ về điều đó, chúng tôi có tình huống tốt nhất có thể. Bạn có thể thay đổi các url trên máy chủ, trong khi vẫn chọn hỗ trợ khách hàng cũ miễn là chúng tôi chọn và khách hàng thông minh có thể tự động cập nhật chính xác các url mới.

Thời gian bạn chọn tiếp tục hỗ trợ các url cũ thực sự là một quyết định cần được thực hiện dựa trên các khách hàng hiện tại và sự dễ dàng mà họ có thể được duy trì.

Đối với tôi, đây là một cải tiến lớn so với các vấn đề về phiên bản với giao diện kiểu RPC.

Answer 4

Tôi biết đây là một câu hỏi cũ, nhưng tôi nghĩ có một thành phần phụ cho các câu trả lời mà tôi thấy ở đây chưa được giải quyết.

Hãy nhớ rằng bạn không truy xuất tài nguyên từ máy chủ, nhưng bạn đang truy xuất ĐẠI DIỆN tài nguyên. Bản thân tài nguyên có thể có thay đổi định danh chính của nó hoặc được khôi phục hoặc bất kỳ điều gì, nhưng biểu diễn được trả lại cho máy khách về tạo tài nguyên có thể (hoặc có thể không) hợp lệ độc lập; đó là tất cả vấn đề của tình huống.

Ví dụ: xem xét hệ thống tải lên nội dung được kiểm duyệt; người dùng có thể có khả năng tải lên nội dung để người kiểm duyệt xem xét và cuối cùng có thể khiến nội dung tiếp xúc với đối tượng/thị trường rộng lớn hơn. Khi tải lên lần đầu, máy chủ có thể phản hồi bằng URI chuyển hướng đến (nói) "người dùng/{userid}/đã tải lên/{contentid}" để trình bày nội dung đó. Tại một thời điểm nào đó, người kiểm duyệt có thể quyết định quảng cáo nội dung cho "trang chủ"; khi đó, biểu diễn nội dung có thể có sẵn tại URI của "content/{contentid}"; không nên ngăn người tải lên ban đầu truy cập vào dữ liệu của họ tại "users/{userid}/uploaded/{contentid}"; không có gì nói rằng cần phải có một chuyển hướng vĩnh viễn, và trên thực tế, có lý do chính đáng để không có; nếu người dùng quyết định họ muốn xóa nội dung, họ sẽ có thể thực hiện DELETE trên nội dung; nó có thể được nhiều ưu đãi để người dùng thực hiện DELETE cho các đại diện nội dung từ các vị trí "đã tải lên" của riêng họ. Tuy nhiên, nếu các điều khoản của trang web cho thấy rằng quyền của người dùng đối với nội dung được tải lên bị thu hồi (không phổ biến), có thể làm cho quy trình quảng bá kiểm duyệt xóa nội dung khỏi khu vực của người dùng một cách hiệu quả, gây ra "di chuyển vĩnh viễn".

Thực sự hoàn toàn phụ thuộc vào tình huống cụ thể; tính hợp lệ của URI được lưu trong bộ nhớ cache hoàn toàn phụ thuộc vào các chính sách của máy chủ. Ít nhất, tôi nghĩ rằng một yêu cầu cho một URI không hợp lệ (có thể đã có hiệu lực trước đây) sẽ gây ra một phản hồi (phù hợp với HATEOAS) có thể cho phép khách hàng "khám phá" tài nguyên (đại diện) mà họ đang tìm kiếm ; ít nhất, một liên kết đến điểm vào.