Pytanie REST najlepsza praktyka do uzyskania listy podzbiorów


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.


12
2018-02-22 13:11


pochodzenie


Myślę, że wszystkie z nich mogą być RESTYCYJNE, ale URL jest tylko jedną częścią bycia RESTYCYJNYM. Mój wybór byłby zgodny z / appointments / patients / user_id = 1234 / date = 2010-02-22, co pozwoliłoby na pozostawienie daty wyłączenia i uzyskanie wszystkich terminów pacjentów dla tego identyfikatora użytkownika. - kenny


Odpowiedzi:


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


5
2018-02-22 13:42



Przechodzę przez dokumenty opensearch. Czy sugerujesz, że każdy zasób na serwerze REST musi być "wykrywalny" przez wywołanie innego adresu URL na serwerze? Nie mogę po prostu opublikować dokumentu, który mówi coś w stylu "Jeśli chcesz uzyskać wszystkie niebieskie widżety, użyj adresu URL" / widgets; color = blue "? - Ralph
To jest poprawne. - Darrel Miller
Tak, jak powiedział Darrel. W pewnym sensie możesz z grubsza myśleć o tym w następujący sposób: podaj dokument, który masz na myśli w formie do odczytu maszynowego (typ mediów) w czasie wykonywania i pozwól klientowi na reakcję. Jan - Jan Algermissen
Czy możesz podać cytat lub obronę dla tego roszczenia: "poszczególne wzorce URI są ortogonalne do pytania, w jaki sposób RESTful będzie Twoja aplikacja"? - David J.
Chcę odeprzeć to stwierdzenie: "poszczególne wzorce URI są ortogonalne w stosunku do pytania, w jaki sposób RESTful będzie miało zastosowanie." Według p. 233 usługi RESTful Web Services autorstwa Richardsona i Ruby, istnieją lepsze i gorsze sposoby konstruowania wzorców URI, aby dopasować je do ich "architektury zorientowanej na zasoby" (ROA). Podsumowując: (1) URI oznaczają zasoby (np. Rzeczowniki), (2) sprawiają, że identyfikatory URI są łatwe do wymieszania przez klientów, (3) używają ukośników, aby przejść od ogólnego do konkretnego, (4) używaj przecinków, gdy zamówienie ma znaczenie, (5) użyj średniki, gdy tak nie jest i (6) używać zmiennych zapytania dla algorytmów. - David J.


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).


2
2018-02-23 22:36



Myślę / appointments / user_id = 1234; date = 2010-02-22 jest nieco lepszy, ponieważ / appointments / nie definiuje punktu w hierarchii. - ocharles


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).


-1
2018-02-24 07:52