2009-12-18 36 views
18

Tôi đang viết một bài báo về việc triển khai một dịch vụ REST cho các tài liệu nghiên cứu của trường đại học và tôi có một vấn đề nhỏ hiểu mối quan hệ giữa URI và Tài nguyên.REST - nhiều URI cho cùng một tài nguyên (???)

Nó nói rằng tài nguyên có thể có một URI hoặc nhiều. Vì vậy, đây là vấn đề của tôi. Tôi muốn làm cho dịch vụ này trở nên dễ sử dụng và thu thập thông tin: tài nguyên nên được truy cập từ các điểm nhập khác nhau, nhưng điều này sẽ đi ngược lại khái niệm, rằng mỗi "URI chỉ định chính xác một tài nguyên".

Vì vậy, câu hỏi của tôi là nếu sau đây là nó hoặc là nó không phù hợp với REST như sau:

Tôi muốn để lộ thông tin về một ấn phẩm nghiên cứu (giả sử một phản biện chuyên gia).

Điều này có thể được truy cập bởi URI này: ĐẠI HỌC/ấn bản/{my_publication}.

Nhưng vì bài viết này được viết bởi một nhà nghiên cứu hoạt động tại Khoa Khoa học Xã hội, nên cũng có nghĩa là ấn phẩm có URI này: ĐẠI HỌC/khoa/social_science/publications/{my_publication}.

Hơn nữa, vì dịch vụ này cũng phơi bày tất cả các nhà nghiên cứu làm việc tại trường đại học (ví dụ: UNIVERSITY/research/{my_researcher}), cũng có nghĩa là ấn bản có thể được đặt tên là UNIVERSITY/research/{my_researcher}/publications/{my_publication}.

Điều này có thể xảy ra với nhiều lần sử dụng, nhưng bạn có ý tưởng.

Điều này có phù hợp với REST hay không?

Tôi có thể giữ điều này và giải quyết tình huống khó xử bằng cách gửi mã phản hồi 303 ("Xem thêm") cùng với URI chuẩn (sẽ là UNIVERSITY/publications/{my_publication}).

Cảm ơn bạn trước!

Trả lời

0

Nó nói rằng tài nguyên có thể có một URI hoặc nhiều. Vì vậy, đây là vấn đề của tôi. Tôi muốn làm cho dịch vụ này trở nên dễ sử dụng và thu thập thông tin: tài nguyên nên được truy cập từ các điểm nhập khác nhau, nhưng điều này sẽ đi ngược lại khái niệm, rằng mỗi "URI chỉ định chính xác một tài nguyên".

Tôi không nghĩ có bất kỳ mâu thuẫn nào ở đây. URI có thể trỏ đến nhiều nhất một tài nguyên, nhưng nhiều URI có thể trỏ đến cùng một tài nguyên. Mối quan hệ nhiều-một giữa các URI và tài nguyên, nếu bạn muốn.

Điều đó nói rằng, tôi sẽ không lo lắng quá nhiều về việc liệu ứng dụng của bạn có RESTful hay không. Nó chỉ là một nguyên tắc thiết kế. Đây là một bài viết hay của một anh chàng cho rằng REST thực sự không dành cho con người với trình duyệt web: http://starkravingcoder.blogspot.com/2009/01/where-are-rest-frameworks.html

6

Trong khi mỗi tài liệu xuất bản phải có một và chỉ một tên tài nguyên (URI), bạn được tự do tạo tài nguyên là truy vấn và danh sách trả về của các tên tài nguyên khác.

Bạn có thể có UNIVERSITY/publication/{publication} làm mẫu tên tài nguyên cho tài nguyên xuất bản và UNIVERSITY/faculties/{faculty}/publications làm mẫu để đặt tên tài nguyên là danh sách ấn phẩm cho các khoa cụ thể.Tương tự, UNIVERSITY/researchers/{researcher}/publications có thể là mẫu tên tài nguyên cho danh sách các ấn phẩm được tác giả bởi một người cụ thể.

+0

Xin chào Jim, đó chính xác là những gì tôi đã làm. Tôi thậm chí còn đi xa hơn, nhưng cũng đặt tên cho các nguồn tài liệu cho từng viện nghiên cứu (/ giảng viên/viện/ấn phẩm) và vân vân. Đó không phải là tình thế tiến thoái lưỡng nan của tôi, nhưng thực tế là không có vấn đề gì về URI mà tôi có trước {my_publication}, URI chỉ trên một và cùng một nguồn tin: bản thân ấn phẩm, đó là duy nhất. –

+0

@jan, Không chắc chắn nếu địa chỉ này bình luận của bạn, nhưng mỗi truy vấn có thể là một tài nguyên REST giống như mỗi ấn phẩm được. Truy vấn đúng cách chỉ nên chứa danh sách các ấn phẩm * tên *. Vì vậy, một khách hàng của dịch vụ web của bạn đầu tiên có thể nhận được danh sách tất cả các ấn phẩm từ Viện Khoa học Thông tin của USC, và sau đó nhận được mỗi ấn phẩm trong danh sách đó. –

0

+1 cho Jim Ferrans.

Ngoài ra, việc có chính xác một URI cho mỗi tài nguyên sẽ giúp bạn tạo liên kết dễ dàng hơn trong trang web của mình. Tôi đã đọc rằng các công cụ tìm kiếm thích nội dung không được lặp lại tại các URI khác nhau.

+0

Đó là sự thật, và một ưu điểm khác là nếu bạn chỉ có một tên duy nhất cho mỗi tài nguyên, thì sẽ dễ dàng hơn nhiều nếu bạn có một loạt các từ đồng nghĩa. –

22

Nó nói rằng tài nguyên có thể có một URI hoặc nhiều. Vì vậy, đây là vấn đề của tôi. Tôi muốn làm cho dịch vụ này trở nên dễ sử dụng và thu thập thông tin: tài nguyên nên được truy cập từ các điểm nhập khác nhau, nhưng điều này sẽ đi ngược lại khái niệm, rằng mỗi "URI chỉ định chính xác một tài nguyên"

Không nó không. "Mỗi ngón tay thuộc về chính xác một bàn tay" không ngụ ý "mỗi bàn tay có chính xác một ngón tay". "Mỗi URI chỉ định chính xác một tài nguyên" không ngụ ý "mọi tài nguyên được chỉ định chính xác một URI".

Điều đó nói rằng, chuyển hướng đến URI chuẩn sẽ cải thiện một số trường hợp sử dụng (chẳng hạn hai người dùng đánh dấu cùng một giấy trên ngon, đã đến đó từ các truy vấn khác nhau).

Bạn cũng có vẻ đang suy nghĩ về việc tạo URL thông qua các mẫu phân cấp, thay vì bất kỳ điều gì về REST. Ứng dụng REST sử dụng "siêu văn bản làm công cụ của trạng thái ứng dụng". Hình thức của URI là không liên quan, điều quan trọng là nó có thể điều hướng từ biểu diễn được trả về tại điểm vào của ứng dụng. Fielding làm cho điều này rõ ràng trong blog của mình REST APIs must be hypertext-driven như một mô hình chống gây khớp nối giữa client và server:

Một REST API không phải xác định tên tài nguyên cố định hoặc phân cấp (một khớp nối rõ ràng của client và server).

+1

Con trai tôi muốn bạn mở rộng đoạn cuối cùng một chút. – ScottCher

+3

@ScottCher Trong một ứng dụng REST, trạng thái của ứng dụng được đại diện bởi tác nhân người dùng tìm nạp tài nguyên thông qua các URL. REST đang nghĩ về một ứng dụng như một máy trạng thái mà mỗi trạng thái là kết quả của việc giải quyết một URL để lấy ra một tài nguyên; các liên kết trong tài nguyên là sự chuyển tiếp sang các trạng thái có thể tiếp theo. Có các liên kết có một mô hình cụ thể có thể đọc được của con người không liên quan đến chính REST, chỉ các liên kết đến trạng thái tiếp theo của ứng dụng nằm bên trong tài nguyên được truy lục cho trạng thái hiện tại. Có cùng trạng thái được đại diện bởi cùng một URL tạo điều kiện ... –

+2

... đánh dấu trang, nhưng có một mẫu mà người dùng có thể đoán là phần nào chống REST - điều đó có nghĩa là người dùng có thể đoán URL, nhập vào và nhảy vào ứng dụng trạng thái không phải là một phần của quy trình làm việc của họ. Đối với rất nhiều trường hợp, đây không phải là một vấn đề, nơi mà nhà nước không phụ thuộc vào việc đã đạt được từ một con đường nhất định, vì vậy khá nhiều ứng dụng REST cho phép nó. Có một mô hình dễ đọc của con người có lợi thế, nhưng không phải là yêu cầu của REST. –

9

Đây là chủ đề được tranh luận thường xuyên và tôi tin rằng sự nhầm lẫn này được dựa trên việc cố gắng hiểu một HTTP URI thực sự trỏ đến điều gì. Dựa trên các bài đọc của tôi, điều này trở thành một chủ đề thực sự lông và mọi người thông minh hơn bản thân tôi đã tranh luận trong nhiều năm về chủ đề này.

Here là trang tóm tắt của tất cả các cuộc thảo luận về vấn đề http-range-14.

Giải thích ngây thơ của tôi về kết luận cuối cùng của vấn đề này là chỉ nên có một URI đơn trả về một "tài nguyên thông tin" vật lý với 200. Tuy nhiên, có thể có nhiều URI tham chiếu đến tài nguyên khái niệm. Trả lại 303 cho phép bạn liên kết khái niệm này với "tài nguyên thông tin". Vì vậy, câu trả lời là có và không, có thể có nhiều URI cho cùng một tài nguyên và tất cả đều hợp lệ để biểu diễn khái niệm, nhưng chỉ có một thực sự nên trả về biểu diễn vật lý.

Điều này phù hợp với nhận xét gần đây của Roy Fielding khi nói về việc sử dụng ".xml" và ".json" trong URI. Ông tuyên bố khá rõ ràng rằng http://www.example.org/myresource.xmlhttp://www.example.org/myresource.json đang đề cập đến hai TÀI NGUYÊN khác nhau vì chúng đều trả về 200. Tuy nhiên, khi bạn sử dụng thương lượng nội dung trên http://www.example.org/myresource bạn có thể truy xuất hai đại diện khác nhau của cùng một tài nguyên.

0

Bạn cần thấy sự khác biệt giữa tài nguyên và đối tượng mà nó đại diện. Roy Fielding viết trong dissertation, section 5.2.1.1 mình:

Một tài nguyên là một ánh xạ khái niệm để một tập hợp các thực thể, không đơn vị tương ứng với bản đồ tại bất kỳ điểm cụ thể trong thời gian .

Vì tất cả các tài nguyên của bạn mang ngữ nghĩa hơi khác nhau, có thể coi RESTful là ý kiến ​​của tôi. Tùy thuộc vào cấu trúc của loại phương tiện truyền thông của bạn, bạn có thể sử dụng canonical link relation để chỉ ra "uri ưu tiên".

Các vấn đề liên quan