REST - jak zaprojektować URI z kluczami kompozytowymi?

Question

Mam pytanie dotyczące sposobu projektowania URI zasobu z kluczami złożonymi.

Mam zasób o nazwie fracht, który ma 4 klucze/identyfikatory: identyfikator partnera, początkowy kod pocztowy, końcowy kod pocztowy i wagę.

Właściwie mój zasób został zaprojektowany, aby mieć przyrostową identyfikator generowany przez bazę danych, ale takie podejście nie jest tak dobry dla konsumentów API, na przykład jeżeli konsument/partnerem musi zaktualizować informacje towarowego mają robić:

?

GET towarowy initialZipcode = {value} & finalZipcode = {value} & waga = {value}

odpowiedź operacji powyżej byłby ID ładunki, więc w końcu można je zaktualizować informacje:

PUT ładunek/{ID}

Identyfikator partnera jest niejawny w mechanizmie uwierzytelniania.

Wydaje mi się dziwne, że partnerzy muszą uzyskać identyfikator ładunku przed zaktualizowaniem informacji.

Moje pytanie brzmi: jak zaprojektować ten identyfikator URI?

PUT towarowy/initialZipcode/{value}/finalZipCode/{value}/waga/{value}

Czy ja rozważyć zaprojektowanie powyżej?

Kolejne pytanie: czy dobrą praktyką jest umieszczanie identyfikatora partnera w mechanizmie uwierzytelniania? Znam plusy (łatwe dla konsumentów) i minusy (pamięć podręczna, niemożność udostępnienia URI itp.), Ale nie wiem, czy ogólnie jest to dobra czy zła praktyka.

Dzięki!

Answer 1

Nie ma nic złego w

PUT freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE} 

parametry zapytań są częścią identyfikacji zasobów zbyt.

Parametry ścieżki są przydatne do definiowania zasobów ładnie pasujących w hierarchii. W twoim przypadku zasób nie pasuje do hierarchii, więc nie próbuj wyciskać parametrów do segmentów ścieżki.

Jedynym wyzwaniem jest to, co zrobić, gdy klient ponownie uporządkuje kolejność parametrów zapytania. Czy traktujesz to jako ten sam zasób, czy też 404? Jeśli nie buforujesz odpowiedzi GET, to prawdopodobnie nie ma to znaczenia.

Jeśli podałeś klientowi szablon URI do wypełnienia, wówczas istnieje mniejsza szansa, że ​​podadzą ci parametry w niewłaściwej kolejności.

---

Inną opcją, jeśli się z oryginalną propozycją jest to, że GET zwraca przekierowanie i nagłówek do URI lokalizacja z identyfikatorem towarowego. na przykład

GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE} 
=> 
302 See Other 
Location: freight/1232321322 

Dzięki temu klient nie musi nic wiedzieć o ID towarowego, może po prostu chwycić nagłówek lokalizacji i wykonaj przekierowanie zrobić GET, PUT lub zrobić bezpośrednio przed jakimkolwiek URI znajduje się w nagłówku Location.Oznacza to, że jeśli zdecydujesz, że nie chcesz ujawniać identyfikatora w przyszłości, możesz zmienić identyfikator URI bez naruszania jakichkolwiek klientów.