Khi nào cần bao gồm các mục con trong phần trình bày tài nguyên RESTful?

Question

Thiết kế RESTful dường như ủng hộ các biểu diễn có cấu trúc phẳng hoặc nông (ít nhất là khi các tài nguyên được biểu diễn dưới dạng XML). Một biểu diễn tài nguyên chỉ nên chứa tài nguyên mà URI xác định. Tôi tự hỏi khi nào nó là hợp lý để trình bày các nguồn tài nguyên phụ của tài nguyên trong tài nguyên chính?

Để xây dựng, hãy xem xét điều này: Công ty có thể có nhiều nhân viên. Thông thường tình huống này có lẽ sẽ được thiết kế như hai nguồn lực riêng biệt, công ty và nhân viên, nơi nhân viên sẽ là tài nguyên phụ của công ty.

/company/acme/ 
/company/acme/employees/ 
/company/acme/employee/john 

Với thiết kế URI này, đại diện công ty phải bao gồm các liên kết đến nhân viên, nhưng biểu diễn XML có thể không bao gồm emplyoyees per se.

Vì vậy, khi nào có ý nghĩa khi đưa các mục con thông qua phụ huynh? Và có một tình huống mà nó sẽ là hợp lý để trình bày tiểu mục chỉ thông qua cha mẹ của họ. Tôi có nghĩa là sẽ không có URI cho các mục phụ. Chúng chỉ có thể đạt được thông qua tài nguyên chính.

<company> 
<name>Acme</name> 
<employees> 
    <employee>John</employee> 
    <employee>Jack</employee> 
</employees> 
</company> 

Có hợp lý để cung cấp phương pháp duy nhất để truy cập vào một tài nguyên: nếu cha mẹ cho thấy nó tiểu mục, có thể có một URI rõ ràng cho các tiểu mục quá? Vì vậy, nếu XML của công ty chứa các nhân viên của công ty, sẽ có ý nghĩa khi cung cấp/công ty/acme/nhân viên URI bất chấp rằng bạn có thể nhận được cùng một thông tin thông qua tài nguyên của công ty không?

Answer 1

Nếu tài nguyên phụ chỉ có ý nghĩa trong ngữ cảnh của cha mẹ, thì có, nó phải được trả về lồng nhau trong cha mẹ của nó. Ví dụ: trong HTML, phần tử <li> không có ý nghĩa như một tài nguyên phụ.

Tuy nhiên, nếu tài nguyên có thể đứng một mình và bạn sẽ muốn thao tác tài nguyên độc lập với bất kỳ tài nguyên nào khác, thì cần có URI riêng. Bằng cách đó, bạn có thể POST hoặc PUT đến tài nguyên đó mà không ảnh hưởng đến các tài nguyên có liên quan khác và không phải vẹt chúng trở lại máy chủ. Nếu bạn phải thao tác mọi thứ từ cha mẹ, hãy nghĩ về điều gì sẽ xảy ra nếu một người thực hiện GET, sửa đổi một mục con, và sau đó thực hiện một PUT của toàn bộ điều với mục phụ đó đã thay đổi; nếu người khác thay đổi một trong những người khác trong thời gian chờ đợi thì sao? Sau đó, bạn cần phải thêm khóa và ngữ nghĩa giao dịch, đánh bại toàn bộ statelessness của REST.

Đối với yêu cầu GET ít nhất, có thể là một ý tưởng tốt để có một số hình thức giao diện truy vấn hàng loạt, theo đó khách hàng có thể nhận được một số lượng lớn tài nguyên cùng một lúc; phải thực hiện một yêu cầu HTTP mới cho mỗi tài nguyên có thể mất một thời gian dài, vì nó có nghĩa là một chuyến đi khứ hồi mới trên mạng cho mỗi GET. Nó có thể có ý nghĩa để có chức năng cập nhật hàng loạt là tốt. Nhưng nếu bạn muốn có thể thao tác một tài nguyên cùng một lúc, bạn cần cung cấp một URI cho một tài nguyên đó.

Và có, hoàn toàn tốt để có nhiều cách truy cập tài nguyên. Bạn có thể nghĩ về nó như một blog; bạn có thể có được những câu chuyện trên trang chính hoặc trên các trang lưu trữ hoặc bằng cách đi đến liên kết cố định của họ.

chỉnh sửa: Nếu bạn muốn đến một cập nhật hàng loạt mà không cần chạy vào các vấn đề của việc có một khách hàng đưa ra dữ liệu cũ đến máy chủ, về cơ bản bạn có hai lựa chọn:

1. Locking.Một khách hàng nói với máy chủ "Tôi muốn khóa trên toàn bộ tập dữ liệu này", tìm nạp dữ liệu mà nó muốn sửa đổi, sửa đổi dữ liệu, gửi dữ liệu trở lại máy chủ và mở nó.
2. Optimistic concurrency: Khách hàng tải xuống bộ dữ liệu, được đánh dấu bằng một số loại thẻ sửa đổi mà máy chủ thay đổi mỗi khi có dữ liệu mới. Máy khách sửa đổi nó và gửi nó trở lại máy chủ. Nếu bất kỳ dữ liệu nào khác trong tập hợp đã được sửa đổi trong thời gian chờ đợi, thẻ sửa đổi sẽ hết dữ liệu và máy chủ sẽ phản hồi bằng "xin lỗi, dữ liệu của bạn đã lỗi thời, hãy thử lại".

Mỗi loại đều có những lợi thế và cạm bẫy. Vấn đề với khóa là nó là stateful, và do đó không phù hợp với một kiến ​​trúc REST rất tốt. Nếu chương trình máy khách bị treo hoặc chết trong khi nó có khóa, thì dữ liệu đó sẽ bị khóa vĩnh viễn trừ khi bạn có một số loại khóa thời gian chờ, điều này có thể trở nên phức tạp. Khóa cũng có thể dẫn đến bế tắc nếu khách hàng đang thực hiện một số loại giao dịch ưa thích có liên quan đến nhiều khóa. Vấn đề với đồng thời lạc quan là nếu có một tải cao trên một tập dữ liệu, với rất nhiều khách hàng thay đổi nó cùng một lúc, nó có thể mất nhiều, nhiều lần thử trước khi một khách hàng nhất định có thể đăng dữ liệu của nó; trên thực tế, một ứng dụng khách chậm có thể bị cắt hoàn toàn khỏi việc đăng các bản cập nhật vì các khách hàng khác liên tục thay đổi dữ liệu theo cách có nghĩa là các khách hàng chậm thay đổi luôn thất bại.

Bạn cần tự quyết định xem tùy chọn nào phù hợp với mình. Những vấn đề này cũng xuất hiện khi thay đổi một tài nguyên (một bản cập nhật có thể khác), nhưng khi bạn tổng hợp tài nguyên vào giao diện hàng loạt, chúng sẽ xuất hiện thường xuyên hơn nhiều. Đó là lý do tại sao tôi khuyên bạn nên có hai giao diện, nếu bạn đang đi để tổng hợp tài nguyên; một trong đó tài nguyên có thể được truy cập riêng lẻ và một giao diện hàng loạt tùy chọn, nơi nhiều tài nguyên có thể được đọc và viết cùng một lúc.