Czy sesje po stronie serwera naruszają REST?

Zgodnie z Royem Fieldingiem (jednym z głównych autorów specyfikacji HTTP) w swojej pracy dyplomowej Style architektoniczne podczas omawiania REST , wspomina:

[E] Żądanie od klienta do serwera musi zawierać wszystkie informacje niezbędne do zrozumienia żądania i nie może korzystać z żadnego kontekstu przechowywanego na serwerze.

Przez „zapisany kontekst” odnosi się do stanu aplikacji, np. Jaki jest numer strony dla następnej strony, w porównaniu do stanu zasobów, np. Dowolnego magazynu danych, obrazu itp. - co jest prawdopodobnie całym celem REST.

Czy można uczciwie powiedzieć, że większość prób czystego odpoczynku (definiowanych niniejszym jako implementacja zgodna z powyższą tezą) musi zakończyć się niepowodzeniem z powodu polegania na przechowywaniu danych sesji na serwerze (trwałym lub innym)?

Pojęcie sesji jest wspólne - w szczególności dla programistów stron internetowych - ale czy jest zgodne z powyższą definicją?

Powiedziałbym, że tak, stan sesji powoduje, że aplikacja RESTful nie jest RESTful. Trywialny przykład, moja siostra subskrybuje Wall Street Journal. Regularnie będzie czytać coś za zapłatą i zdecydować o wysłaniu linku (za pośrednictwem własnego klienta e-mail, a nie przez WSJ) do znajomego, który nie ma konta WSJ. Kliknij, wyślij, nie powiodło się. Oczywiście doświadczenie mojej siostry pod tym adresem URL różni się od doświadczenia jej przyjaciółki.

Powiązane, ale nie wyłącznie na temat: Jestem we wczesnej fazie projektowania aplikacji zaprojektowanej w celu wspierania znacznych wysiłków badawczych w sieci (zwanych zadaniami (pomyśl: zakładki na sterydach i LSD)). Właściciel zadania chce udostępnić konkretny widok swoich danych komuś innemu, ale ten widok wymaga kombinacji stanu interfejsu użytkownika (np. Które wizualizacje danych pokazują, w których oknach) oraz odpowiednich uprawnień dostępu do interfejsu użytkownika i wyświetlane dane. Odbiorca musi uzyskać dużo stanu zapisanego, aby uzyskać zamierzony widok.

Moje obecne rozwiązanie polega na przechowywaniu wszystkich informacji o interfejsie użytkownika / ACL / dowolnych informacjach niezbędnych do widoku w osobnym obiekcie i zwrócenie adresu URL (prawdopodobnie UUID) dla tego obiektu. Uważam, że dostęp do obiektu widoku można uznać za RESTful w tym sensie, że każdy, kto go posiada, otrzymuje te same informacje / doświadczenia.

Czy sesje po stronie serwera naruszają REST?

Zdecydowanie tak! Po wdrożeniu REST nie może być sesji po stronie serwera, w przeciwnym razie masz hybrydowe rozwiązanie RPC / REST.

Klient musi wysłać do usługi RESTful cały kontekst niezbędny do obsługi żądania, w tym informacje niezbędne do uwierzytelnienia klienta, za każdym razem, gdy jest wysyłane nowe żądanie. Serwer może buforować informacje, aby przyspieszyć obsługę kolejnych żądań, ale buforowane informacje nie mogą oznaczać sesji po stronie serwera. Innymi słowy, samo żądanie musi zawierać wystarczającą ilość informacji do przetworzenia nawet przy braku stanu buforowanego.

Prawdopodobnie zależy od tego, co rozumiesz przez „dane sesji”. Czy to dokładny termin?

Bezpieczna komunikacja między dwiema stronami często wymaga od serwera wygenerowania (i przechowywania) ograniczonego czasowo „tokena dostępu”, który klient musi dostarczyć przy każdym żądaniu jako sposób autoryzacji. Ten token dostępu jest już tym, co nazwałbym „danymi sesji” - jest przechowywany po stronie serwera, ograniczony czasowo i powiązany z jednym klientem (zwykle jego uprawnieniami).

Byłbym bardzo zaskoczony, gdyby tego rodzaju operacja została oznaczona jako nie-RESTful. OAuth jest przykładem.

Nie jestem specjalistą i nie jestem zbyt pewny siebie; Po prostu dzielę się swoimi spostrzeżeniami, mając nadzieję, że okażą się pomocne.

Najważniejszym punktem usługi REST jest to, że identyfikator URI dla zasobu zawsze wskazuje na ten sam zasób. Użytkownicy mogą więc przekazywać odniesienia do tego zasobu i każdy widzi to samo. Nazywa się to REST (Representational State Transfer). Jeśli serwer zachowuje stan i dostarcza inne zasoby dla tego samego identyfikatora URI, powiedziałbym, że nie jest to już czysty REST.

Sesje są zasadniczo używane do dodawania stanu do bezstanowych aplikacji RESTful. Formalnie sprawia to, że twoja aplikacja RESTful jest stanowa, jednak utrzymanie stanu serwera sprawia, że ​​twoje życie jest trochę łatwiejsze, ponieważ nie musisz przekazywać wszystkich danych tam iz powrotem przy każdym żądaniu / odpowiedzi.

Sesje, a bardziej ogólnie stan, pozwalają tego uniknąć, a to ma pewne pozytywne zalety pod względem wydajności (mniej przesyłanych danych) i bezpieczeństwa (mniej danych dostępnych do manipulowania).

Więc chociaż oficjalnie narusza część definicji REST, jest tak przydatna, że ​​rzadko można zobaczyć aplikacje RESTful, które nie używają stanu przez sesje.

Przez Fielding rozumiane przez tę instrukcję jest to, że serwer aplikacji obsługujący interfejs API REST nie kojarzy stanu otoczenia z żądaniem jakiegoś mechanizmu ukrytego. Rozważ różnicę między serwerem aplikacji a serwerem bazy danych . Ograniczeniem REST jest to, że serwer aplikacji powinien być bezstanowy . Serwer aplikacji może jednak delegować żądania stanu zasobów do serwera bazy danych na podstawie informacji, które są częścią żądania, takich jak kombinacja użytkownik / hasło w nagłówku autoryzacji lub sam Uri. W końcu REST opiera się na modelu klient / serwer.