RESTful Login Failure: Zwróć 401 lub Custom Response

To jest pytanie koncepcyjne.

Mam aplikację kliencką (mobilną), która musi obsługiwać akcję logowania przeciwko usłudze internetowej RESTful. Ponieważ usługa internetowa jest RESTful, oznacza to, że klient akceptuje nazwę użytkownika / hasło od użytkownika, weryfikując tę ​​nazwę użytkownika / hasło w usłudze, a następnie po prostu pamiętając, aby wysłać tę nazwę użytkownika / hasło ze wszystkimi kolejnymi żądaniami.

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

Pytanie brzmi, kiedy odpytywam usługę sieciową, aby dowiedzieć się, czy podana nazwa użytkownika / hasło są poprawne, czy usługa sieciowa zawsze powinna odpowiadać danymi JSON informującymi o powodzeniu lub niepowodzeniu, czy też powinna zwracać HTTP 200 o dobrych poświadczeniach i HTTP 401 na złe poświadczenia.

Pytam, że niektóre inne usługi RESTful używają 401 dla złych poświadczeń, nawet gdy pytasz tylko, czy poświadczenia są poprawne. Jednak moje zrozumienie odpowiedzi 401 polega na tym, że reprezentują zasób, do którego nie masz dostępu bez ważnych poświadczeń. Ale zasób logowania POWINIEN być dostępny dla każdego, ponieważ cały cel zasobu logowania polega na poinformowaniu użytkownika, czy poświadczenia są poprawne.

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

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

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

myservice.com/are/these/credentials/valid

nigdy nie powinien zwracać 401, ponieważ ten konkretny URL (żądanie) jest autoryzowany z lub bez ważnych poświadczeń.

Chciałbym usłyszeć w tej czy innej sprawie uzasadnione opinie. Jaki jest standardowy sposób postępowania z tym problemem i czy standardowy sposób postępowania jest logicznie odpowiedni?

questionAnswers(2)

yourAnswerToTheQuestion