Błąd logowania RESTful: Zwróć 401 lub odpowiedź niestandardową

To jest pytanie koncepcyjne.

Mam aplikację kliencką (mobilną), która musi obsługiwać akcję logowania do usługi sieciowej RESTful. Ponieważ usługa sieciowa jest zgodna z REST, oznacza to, że klient akceptuje nazwę użytkownika / hasło od użytkownika, weryfikuje tę nazwę użytkownika / hasło w usłudze, a następnie po prostu pamięta o wysyłaniu tej nazwy użytkownika / hasła przy wszystkich kolejnych żądaniach.

Wszystkie inne odpowiedzi w tej usłudze internetowej są dostarczane w formacie JSON.

Pytanie brzmi, kiedy wysyłam zapytanie do usługi sieciowej, aby po prostu dowiedzieć się, czy podana nazwa użytkownika / hasło są prawidłowe, czy usługa sieciowa powinna zawsze odpowiadać danymi JSON informującymi mnie o pomyślnym lub nieudanym wyniku, czy też powinna zwrócić HTTP 200 przy dobrych poświadczeniach i HTTP 401 na złych poświadczeniach.

Powodem, dla którego pytam, jest to, że niektóre inne usługi RESTful używają 401 dla złych poświadczeń, nawet gdy pytasz tylko, czy poświadczenia są prawidłowe. Jednak rozumiem, że odpowiedzi 401 są takie, że reprezentują one zasoby, do których nie powinieneś mieć dostępu bez ważnych poświadczeń. Jednak zasób logowania POWINIEN być dostępny dla każdego, ponieważ jedynym celem zasobu logowania jest poinformowanie Cię, czy Twoje poświadczenia są ważne.

Innymi słowy, wydaje mi się, że taka prośba:

myservice.com/this/is/a/user/action 

powinien zwrócić 401, jeśli podano nieprawidłowe poświadczenia. Ale prośba taka jak:

myservice.com/are/these/credentials/valid

nigdy nie powinien zwracać 401, ponieważ ten konkretny adres URL (żądanie) jest autoryzowany z ważnymi poświadczeniami lub bez nich.

Chciałbym usłyszeć kilka uzasadnionych opinii w tej czy innej sprawie. Jaki jest standardowy sposób radzenia sobie z tym i czy standardowy sposób postępowania jest logicznie odpowiedni?

Po pierwsze. 401 to poprawny kod odpowiedzi do wysłania w przypadku niepowodzenia logowania.

401 Unauthorized Podobny do 403 Zabroniony, ale specjalnie do użycia, gdy uwierzytelnianie jest wymagane i nie powiodło się lub nie zostało jeszcze dostarczone. Odpowiedź musi zawierać pole nagłówka WWW-Authenticate zawierające wezwanie mające zastosowanie do żądanego zasobu.

Twoje zamieszanie na temat myservice.com/are/these/credentials/valid odsyłaniem 401, gdy po prostu robisz czek, jest oparte na fakcie, że wykonywanie żądań logicznych w REST często jest błędne z powodu ograniczeń RESTful. Każde żądanie powinno zwrócić zasób. Zadawanie pytań logicznych w usłudze RESTful to śliski spadek do RPC.

Teraz nie wiem, jak zachowują się usługi, na które patrzyłeś. Ale dobrym sposobem rozwiązania tego problemu jest posiadanie czegoś w rodzaju obiektu Konto, który próbujesz uzyskać. Jeśli twoje dane uwierzytelniające są poprawne, otrzymasz obiekt Account, jeśli nie chcesz marnować przepustowości tylko na „sprawdzenie”, możesz wykonać HEAD na tym samym zasobie.

Obiekt konta jest również dobrym miejscem do przechowywania wszystkich tych nieznośnych wartości logicznych, dla których w innym przypadku trudno byłoby utworzyć indywidualne zasoby.

401 należy wysłać tylko wtedy, gdy żądanie wymaga pola nagłówka autoryzacji i autoryzacja się nie powiedzie. Ponieważ interfejs API logowania nie wymaga autoryzacji, stąd 401 to moim zdaniem zły kod błędu

Zgodnie ze standardem tutaj https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

* 10.4.2 401 Brak autoryzacji

Żądanie wymaga uwierzytelnienia użytkownika. Odpowiedź MUSI zawierać nagłówek WWW-Authenticate (sekcja 14.47) zawierający wezwanie mające zastosowanie do żądanego zasobu. Klient MOŻE powtórzyć żądanie z odpowiednim nagłówkiem Authorization (rozdział 14.8). Jeśli żądanie zawierało już poświadczenia autoryzacji, odpowiedź 401 wskazuje, że odmówiono autoryzacji dla tych poświadczeń. Jeżeli odpowiedź 401 zawiera to samo wezwanie, co poprzednia odpowiedź, a agent użytkownika już co najmniej raz próbował uwierzytelnić, wówczas użytkownikowi POWINIEN zostać przedstawiona jednostka, która została podana w odpowiedzi, ponieważ jednostka ta może zawierać istotne informacje diagnostyczne. Uwierzytelnianie dostępu HTTP jest wyjaśnione w rozdziale „Uwierzytelnianie HTTP: uwierzytelnianie podstawowe i cyfrowe” [43]. *

Zwróć 409 z odpowiednim komunikatem o błędzie.