RESTful-Anmeldefehler: Rückgabe 401 oder benutzerdefinierte Antwort

Question

Dies ist eine konzeptionelle Frage.

Ich habe eine Client (mobile) Anwendung, die eine Login-Aktion gegen einen RESTful Web-Service unterstützen muss. Da der Webdienst RESTful ist, bedeutet dies, dass der Client einen Benutzernamen/ein Passwort vom Benutzer akzeptiert, dass er den Benutzernamen/das Passwort mit dem Service bestätigt und sich dann daran erinnert, diesen Benutzernamen/Passwort mit allen nachfolgenden Anfragen zu senden.

Alle anderen Antworten in diesem Webdienst werden in einem JSON-Format bereitgestellt. Die Frage ist, wenn ich den Webservice einfach abfrage, um herauszufinden, ob ein Benutzername/Passwort gültig ist, sollte der Webservice immer mit JSON-Daten antworten, die mir seine erfolgreiche oder nicht erfolgreiche Antwort geben, oder sollte er HTTP 200 zurückgeben gute Anmeldeinformationen und HTTP 401 für ungültige Anmeldeinformationen.

Der Grund, warum ich frage, ist, dass einige andere RESTful-Dienste 401 für schlechte Anmeldeinformationen verwenden, selbst wenn Sie nur fragen, ob die Anmeldeinformationen gültig sind. Mein Verständnis von 401-Antworten ist jedoch, dass sie eine Ressource darstellen, auf die Sie ohne gültige Anmeldeinformationen keinen Zugriff haben sollten. Aber die Login-Ressource sollte für jeden zugänglich sein, denn der gesamte Zweck der Login-Ressource ist es, Ihnen zu sagen, ob Ihre Anmeldedaten gültig sind.

Anders ausgedrückt, scheint es mir, dass eine Anfrage wie:

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

401 zurückkehren soll, wenn schlechte Anmeldeinformationen zur Verfügung gestellt werden. Aber eine Anfrage wie:

sollte nie 401 zurückgeben, weil diese bestimmte URL (Anfrage) mit oder ohne gültige Anmeldeinformationen berechtigt ist.

Ich würde gern einige berechtigte Meinungen auf die eine oder andere Weise zu diesem Thema hören. Was ist der übliche Weg, um dies zu handhaben, und ist der Standard Weg, dies logisch sinnvoll zu behandeln?

Answer 1

Zunächst. 401 ist der richtige Antwortcode, der gesendet wird, wenn eine fehlgeschlagene Anmeldung erfolgt ist.

401 Unauthorized ähnlich 403 Verboten, aber speziell für den Einsatz, wenn eine Authentifizierung erforderlich ist und ausgefallen ist oder noch nicht zur Verfügung gestellt. Die Antwort muss ein WWW-Authenticate-Headerfeld enthalten, das eine Abfrage enthält, die für die angeforderte Ressource gilt.

Ihre Verwirrung über, myservice.com/are/these/credentials/valid zurückschicken 401, wenn Sie nur einen Scheck zu tun, ich denke, ist auf die Tatsache, dass oft tun boolean Anfragen in REST durch die RESTful Zwänge falsch ist. Jede Anfrage sollte eine Ressource zurückgeben. Boolesche Fragen in einem REST-fähigen Dienst zu erledigen, ist eine schlüpfrige Sloop nach RPC.

Jetzt weiß ich nicht, wie die Dienste, die Sie betrachteten, sich benehmen. Aber ein guter Weg, dies zu lösen, ist, etwas wie ein Account-Objekt zu haben, das Sie versuchen zu bekommen. Wenn Ihre Anmeldeinformationen korrekt sind, erhalten Sie das Account-Objekt. Wenn Sie keine Bandbreite verschwenden wollen, um nur einen "Check" durchzuführen, können Sie HEAD für dieselbe Ressource ausführen.

Ein Account-Objekt ist auch ein schöner Ort, um alle diese lästigen booleschen Werte zu speichern, für die es sonst schwierig wäre, individuelle Ressourcen zu erstellen.