Przeczytałem artykuł pod adresem REST - złożone aplikacje i odpowiada na niektóre z moich pytań, ale nie wszystkie.
Projektuję swoją pierwszą aplikację REST i muszę zwrócić listy "podzbiorów" do żądań GET. Który z poniższych jest bardziej "REST"?
/patients;listType=appointments;date=2010-02-22;user_id=1234
lub
/patients/appointments-list;date=2010-02-22;user_id=1234
lub nawet
/appointments/2010-02-22/patients;user_id=1234
Będzie około tuzin różnych list, które muszę zwrócić. W niektórych z nich będzie kilka parametrów filtrowania i nie chcę mieć dużych instrukcji "if" w moim kodzie serwera, aby wybrać podzestawy na podstawie których parametry są obecne. Na przykład, mogę potrzebować wszystkich pacjentów dla konkretnego lekarza, w którym lekarz okrywający jest inny, a główny lekarz to jeszcze jeden. Mogę wybrać z
/patients;rounds=true;specific_id=xxxx;covering_id=yyyy;primary_id=zzzz
ale wymagałoby to skomplikowanej logiki rozgałęzień, aby uzyskać właściwą listę, gdzie zapytanie o określony podzbiór (rund-list) pozwoli osiągnąć to samo.
Zauważ, że muszę używać parametrów macierzy zamiast parametrów zapytania, ponieważ muszę wykonać filtrowanie na kilku poziomach adresu URL. Framework, którego używam (RestEasy), w pełni obsługuje parametry macierzy.
Ralph,
poszczególne wzorce URI są ortogonalne w stosunku do pytania, w jaki sposób RESTful będzie Twoja aplikacja.
Dla RESTfulness liczy się to, że klient odkrywa jak zbudować URI W czasie wykonywania. Można to osiągnąć za pomocą formularzy lub szablonów URI. Obie kontrolki hipermedialne informują klienta, jakie parametry mogą być używane i gdzie umieścić je w URI.
Aby to działało RESTfully, klient i serwer muszą znać możliwe parametry w czasie projektowania. Zwykle jest to osiągane przez uczynienie ich częścią specyfikacji powiązania łącza.
Możesz na przykład zdefiniować relację łącza "mój-podzbiór", aby mieć znaczenie łączenia z podzbiorami kolekcji, a wraz z nią zdefiniowałbyś następujące parametry:
listType, date, userID.
W szablonie linku, którego specyfikację można użyć jako
<link rel = "mój-podzbiór" template = "/ {listType} / {date} / patients; user_id = {userID}" />
Zwróć uwagę, że rzeczywista nazwa parametru w identyfikatorze URI jest oddzielona od podanej nazwy parametru. Wartość identyfikatora użytkownika jest późno związana z parametrem identyfikatora URI identyfikator_użytkownika.
Umożliwia to zmianę nazwy parametru URI bez wpływu na klienta.
Możesz przejrzeć dokumenty opisu OpenSearch (http://www.opensearch.org), aby zobaczyć, jak to się dzieje w praktyce.
Właściwie, powinieneś być w stanie wykorzystać OpenSearch całkiem sporo dla twojego przypadku użycia. Szczególnie możliwość predefiniowania zapytań pozwoliłaby opisać poszczególne podzbiory w twoich "formularzach".
Ale przekonaj się sam, a następnie zapytaj ponownie :-)
Jan
Zalecam użycie tej struktury adresu URL:
/appointments;user_id=1234;date=2010-02-22
Czemu? wybieram /appointments ponieważ jest prosty i jasny. (Jeśli masz więcej niż jeden rodzaj spotkań, daj mi znać w komentarzach i mogę dostosować moją odpowiedź.) Wybrałem średniki, ponieważ nie implikują one hierarchii pomiędzy user_id a date.
Jeszcze jedno, nie ma powodu, dla którego powinieneś ograniczyć się do jednego adresu URL. Dobrze jest mieć wiele struktur URL, które odnoszą się do tego samego zasobu. Więc możesz również użyć:
/users/1234/appointments;date=2010-02-22
Aby zwrócić podobny wynik.
Powiedział, że nie polecam używania /dates/2010-02-22/appointments;user_id=1234. Czemu? Nie sądzę, w praktyce, że /dates odnosi się do zasobu. Data jest atrybutem terminu, ale sama nie jest rzeczownikiem (tzn. Nie jest rzeczą najwyższej jakości).
Mogę odnieść się do odpowiedzi Davida Jamesa.
Format twoich URI może być taki, jak zasugerował:
/appointments;user_id=1234;date=2010-02-22
i / lub
/users/1234/appointments;date=2010-02-22
przy jednoczesnym zachowaniu wykrywalności (w czasie wykonywania) identyfikatorów URI danego zasobu (jak sugerował Jan Algermissen).