Buforowanie REST i URI

Question

Jak rozumiem, przy korzystaniu z usługi RESTful Web przy użyciu usługi hypertext-driven klient nie powinien nic wiedzieć o układzie URI serwera, z wyjątkiem kilku dobrze znanych punktów wejścia. Ma to na celu umożliwienie serwerowi kontrolowania własnej przestrzeni URI i ograniczenia sprzężenia z klientem.

Gdy klient usługi wyśle ​​pomyślnie żądanie utworzenia nowego zasobu, usługa odpowiada 201 CREATED i podaje identyfikator URI, do którego można uzyskać dostęp do nowego zasobu w polu nagłówka Location.

Czy klient powinien mieć możliwość przechowywania tego identyfikatora URI, aby umożliwić bezpośredni dostęp do zasobu w przyszłości, a jeśli tak, to jak długo? Jeśli identyfikatory URI są buforowane przez klienta, wydaje się, że konfiguruje to sytuację, w której za każdym razem, gdy serwer zmienia swój układ URI, będzie musiał upewnić się, że stałe przekierowanie zostanie obsłużone, gdy uzyskuje się dostęp do starych identyfikatorów URI. W przeciwnym razie klient się zepsuje. W ciągu kilku lat ten system przekierowań może wymknąć się spod kontroli.

Ta sytuacja nie sprawiłaby, że serwer dałby o wiele większą kontrolę nad przestrzenią URI niż podejście hybrydowe REST-RPC za pomocą szablonów URI.

Dostępnych jest wiele informacji na temat zapisów w pamięci podręcznej, ale co z buforowaniem identyfikatorów URI w systemach RESTful sterowanych hipertekstem?

Answer 1

Pamiętaj, że Tim Berners-Lee powiedział: "fajne adresy URL się nie zmieniają". Po przekazaniu przez serwer identyfikatora URI do klienta, zadaniem serwera jest utrzymanie identyfikatora URI w przyszłości poprzez (na przykład) wysłanie odpowiedzi Przeniesienie - Na wypadek, gdyby identyfikator URI się zmienił, a ktoś zażądał starego.

To właśnie zachęca wielu do projektowania nieprzejrzystych identyfikatorów URI, takich jak na podstawie identyfikatorów baz danych lub znaczników czasu, zamiast używania jakiejś czytelnej dla człowieka właściwości zasobu w URI. Wszystko, co ludzie rozumieją, będą chcieli zmienić.

Answer 2

Ponieważ jednym z głównych zasad REST jest to, że zasoby są adresowalne, wydaje się, że klient jest całkowicie do przyjęcia, aby śledzić adres (URI) dla danego zasobu. Identyfikatory URI zasobów powinny być jednym z "dobrze znanych punktów wejścia", o których wspomniałeś.

Answer 3

Tak, klient powinien mieć możliwość przechowywania identyfikatora URI. Tak długo, jak chce. Jak wspomniał Licky, inteligentny klient może użyć opcji Przenieś-Trwale, aby zaktualizować swoje zakładki.

Jeśli myślisz o tym, mamy najlepszą możliwą sytuację. Możesz zmienić adresy URL na serwerze, jednocześnie wybierając opcję obsługi starych klientów tak długo, jak wybierzesz, a inteligentni klienci mogą skutecznie automatycznie aktualizować się do nowych adresów URL.

Czas, w którym zdecydujesz się kontynuować obsługę starych adresów URL, jest decyzją, która musi zostać podjęta w oparciu o obecnych klientów i łatwość, z jaką można je utrzymać.

Dla mnie jest to ogromne ulepszenie w stosunku do problemów związanych z wersjami z interfejsami w stylu RPC.

Answer 4

Wiem, że to stare pytanie, ale myślę, że istnieje podskładnik odpowiedzi, które tutaj widzę, a których nie omówiono.

Pamiętaj, że nie pobierasz zasobu z serwera, ale pobierasz REPREZENTOWANIE zasobu. Sam zasób może mieć swój główny identyfikator, być zmieniany lub być w innym miejscu, ale reprezentacja, która została zwrócona klientowi podczas tworzenia zasobów, może (lub nie musi) być ważna niezależnie; to wszystko kwestia sytuacji.

Jako przykład rozważmy moderowany system przesyłania treści; użytkownik może mieć możliwość przesyłania treści do rozpatrzenia przez moderatorów, którzy mogą w końcu spowodować, że zawartość zostanie udostępniona szerszemu gronu odbiorców/rynku. Przy pierwszym przesłaniu serwer może odpowiedzieć identyfikatorem URI, który kieruje do (powiedzmy) "users/{userid}/uploaded/{contentid}" dla tej reprezentacji tej treści. W pewnym momencie moderatorzy mogą zdecydować o promowaniu treści na "pierwszej stronie"; ta reprezentacja treści może być wtedy dostępna na URI "content/{contentid}"; nie powinno to uniemożliwiać pierwotnemu przesyłającemu dostępu do ich danych w "users/{userid}/uploaded/{contentid}"; nic nie mówi, że musi istnieć stałe przekierowanie, aw rzeczywistości istnieje dobry powód, aby tego nie było; jeśli użytkownik zdecyduje, że chce usunąć zawartość, powinien mieć możliwość wykonania DELETE na treści; Prawdopodobnie jest dużo preferencji, aby użytkownicy robili DELETE do reprezentacji treści z ich własnych "przesłanych" lokalizacji. Jeśli jednak warunki witryny wskazują, że prawa użytkownika do przesłanych treści zostały odwołane (nierzadko), może być sensowne, aby proces moderacji skutecznie usunął treść z obszaru użytkownika, powodując "stały ruch".

To naprawdę całkowicie zależne od konkretnej sytuacji; ważność buforowanego identyfikatora URI jest całkowicie zależna od zasad serwera. Przynajmniej sądzę, że żądanie do nieprawidłowego identyfikatora URI (które mogło być wcześniej ważne) powinno spowodować odpowiedź (zgodną z HATEOAS), która może umożliwić klientowi "ponowne odkrycie" zasobu (reprezentacji), którego szukają ; przynajmniej link do punktu wejścia.