Czy pliki cookie powinny być używane w interfejsie API RESTful?

Szczególnie interesuje mnie sposób, w jaki użytkownicy wykonują autoryzowane / uwierzytelnione operacje w internetowym interfejsie API.

Czy uwierzytelniające pliki cookie są zgodne z filozofią REST i dlaczego?

Idealna usługa ReSTful pozwala klientom (które mogą nie być w przeglądarce) wykonywać dowolne zadania w jednym żądaniu ; ponieważ pełny stan potrzebny do tego jest w posiadaniu klienta, a nie serwera. Ponieważ klient ma pełną kontrolę nad stanem, może sam tworzyć stan (jeśli jest to uzasadnione) i rozmawiać tylko z interfejsem API, aby „załatwić sprawę”.

Wymaganie plików cookie może to utrudnić. Dla klientów poza przeglądarkami zarządzanie plikami cookie jest dość dużą niedogodnością w porównaniu z parametrami zapytań, zwykłymi nagłówkami żądań lub treścią żądania. Z drugiej strony, w przeglądarce korzystanie z plików cookie może znacznie uprościć wiele rzeczy.

Interfejs API może więc najpierw sprawdzić w Authorizationnagłówku potrzebne dane uwierzytelniające, ponieważ prawdopodobnie jest to miejsce, w którym klienci spoza przeglądarki wolą je umieścić, ale aby uprościć i usprawnić klientów opartych na przeglądarce, może również sprawdzić plik cookie sesji do logowania po stronie serwera, ale tylko w przypadku Authorizationbraku zwykłego nagłówka.

Innym przykładem może być złożone żądanie, które zwykle wymaga dużej liczby parametrów. Nieinteraktywny klient nie miałby problemów z zablokowaniem wszystkich tych danych w jednym żądaniu, ale interfejs oparty na formularzu HTML może chcieć podzielić żądanie na kilka stron (coś w rodzaju zestawu stron „kreatora”), aby użytkownicy nie byli prezentowani z opcjami, które nie mają zastosowania na podstawie poprzednich wyborów. Wszystkie strony pośrednie mogą przechowywać wartości w plikach cookie po stronie klienta, dzięki czemu tylko ostatnia strona, na której użytkownik faktycznie przesyła żądanie, ma w ogóle jakikolwiek efekt uboczny po stronie serwera. Interfejs API może wyszukać potrzebne atrybuty w treści żądania i wrócić do przeglądania plików cookie, jeśli nie ma wymaganych parametrów.

Edytuj: w RE do komentarza @ Konrad poniżej:

Tokeny w porównaniu są trudniejsze do wdrożenia, zwłaszcza że nie można łatwo unieważnić tokena bez przechowywania go gdzieś.

er ... sprawdzasz poprawność plików cookie po stronie serwera, prawda? To, że kazałeś przeglądarce odrzucić plik cookie po 24 godzinach, nie oznacza, że ​​tak będzie. Ten plik cookie może zostać zapisany przez wysoce technicznego użytkownika i ponownie użyty długo po jego „wygasnięciu”.

Jeśli nie chcesz przechowywać danych sesji po stronie serwera, powinieneś zapisać je w tokenie (plik cookie lub w inny sposób). Samodzielny token uwierzytelniania jest czasem nazywany makaronikiem. Sposób, w jaki jest przekazywany między klientem a serwerem (czy to przez plik cookie, jako dodatkowe nagłówki, czy w samej jednostce żądania) jest całkowicie niezależny od samego mechanizmu uwierzytelniania.

Tak i nie - zależy od tego, jak z niego korzystasz.

Pliki cookie, jeśli są używane do utrzymania stanu klienta na kliencie, dla klienta, klienta i klienta, są spokojne.

Jeśli zapisujesz stan serwera w pliku cookie, to po prostu przenosisz obciążenie na klienta - co nie jest spokojne.

Jakie są więc przykłady?

Spokojny:

• Dane uwierzytelniające lub „zalogowany” to coś w rodzaju
• ostatnio oglądana strona lub miejsce w aplikacji itp.

Niepokojący:

• Przechowywanie informacji o sesji

Spokój wynika z bezpaństwowości - serwera. Klienci mogą utrzymywać stan aplikacji i wysyłać ją do serwera, aby powiedzieć, gdzie są, aby serwer mógł zdecydować, dokąd się udać. Zasadniczo sesje / stany potrzebują danych historycznych i są zależne od wcześniejszych żądań, że tak powiem, aplikacje relaksujące idealnie nie są (nie jest opłacalne, aby mieć aplikację w 100% czystą, jeśli chcesz mieć ekran logowania :)

Można używać plików cookie. REST pozwala im.

REST wymaga, aby wszelkie informacje o sesji były przechowywane po stronie klienta, ale jeśli chodzi o uwierzytelnianie, niektóre informacje muszą pozostać po stronie serwera ze względów bezpieczeństwa.

Z jednego z moich postów na blogu wynika ogólna zgoda, że ​​dane uwierzytelniające są uznawane za nieobjęte zakresem REST. Dlatego serwery mogą przechowywać niektóre dane sesji po swojej stronie.