Probleme bei der Verwendung des HTTP-Statuscodes-PHP-Tutorial-php.cn

Als Front-End habe ich kürzlich mit dem Schreiben des Back-Ends begonnen und bin auf einige erholsame Designprobleme gestoßen. Ich hoffe, Sie können sie beantworten.
Die Restful-Spezifikation betont besonders die Verwendung von HTTP Status Codes, aber ich habe einige Zweifel bei der Verwendung. Insbesondere im Bereich der Rückgabe von Fehlerinformationen.
Wenn ich es selbst verwende, stimme ich einer Reihe von geschäftsbezogenen Fehlercodes zu, z. B. 20001, die „fehlendes xxx-Feld“ darstellen, ich füge es in den HTTP-Antworttext ein, gebe es zurück und schreibe dann 200 OK im Antwortheader.
Wenn zum Beispiel beim Anmelden kein Passwortfeld im vom Front-End übergebenen JSON vorhanden ist,
dann gebe ich eine 400 Bad Request HTTP-Nachricht zurück, und der Textteil der Nachricht lautet wie folgt ( nur ein Beispiel, halte alles einfach ):

<code>{
"code":20001,
"message":"缺少password字段"
}</code>

Nach dem Login kopieren

Bezüglich der oben genannten Verarbeitungsmethode lautet die Hauptfrage:
Manchmal treten geschäftliche Fehler auf und ich weiß nicht, welche HTTP-Statuscodes ich verwenden soll, wenn beispielsweise beim Erstellen eines neuen Benutzers der Benutzername bereits vorhanden ist , dann ist es zu diesem Zeitpunkt einfach, mit dem Körperteil zu arbeiten, aber welche HTTP-Statuscodes sollten verwendet werden? 400 Bad Request Es muss falsch sein, die vom Frontend gesendeten Informationen sind in Ordnung, 401 Unauthorized 403 Forbidden und das „like“ kann hier nicht verwendet werden. Was sollte ich derzeit für HTTP-Statuscodes verwenden?
Tatsächlich geben viele Schüler unabhängig von der Situation 200 OK zurück und verwenden dann JSON, um Fehlerinformationen im http body zurückzugeben Teil, aber ich habe immer noch das Gefühl, dass HTTP Status Codes ein sehr wichtiger Teil von Restful ist, und die Restful-Spezifikation betont auch seine Verwendung, daher hoffe ich immer noch, dass mir jeder eine Anleitung geben kann, wie man diesen Teil erledigt.

Antwortinhalt:

<code>{
"code":20001,
"message":"缺少password字段"
}</code>

Nach dem Login kopieren

Es wird empfohlen, einen Blick auf die http-Statuscodeliste zu werfen. Es gibt immer noch viele 4xx-Antwortcodes. Im Allgemeinen stellt 4xx auch einen Anforderungsfehler dar.

Die Spezifikationen sind nur allgemeine Vorschläge. Sie können auch eine erstellen. Der Schlüssel liegt darin, sich gut abzustimmen und relevante Dokumente zu hinterlassen.233 ok

Unter der Annahme, dass es in einem Programm vom Typ Website verwendet wird, ist die Website für Benutzer sichtbar. Es stimmt, dass die Webseite nicht existiert und 404 zurückgibt, aber der Webserver übernimmt diese Funktion im Allgemeinen für uns, aber einfach Verwenden Sie eine, wenn etwas schief geht. Den Benutzern ist es egal, wie wissenschaftlich Sie den Rückgabecode festlegen. Sie werden Ihr Konto nicht kaufen mit dem Returncode. Daher können für Websites häufig verwendete Rückgabecodes angegeben werden, der Fokus liegt jedoch auf der angezeigten Seite. Ob der Rückkehrcode 400, 401 oder ähnliches ist, egal wie genau Sie sind, er ist nicht so prägnant und klar wie eine Eingabeaufforderungsseite mit Fehlermeldungen.

Wenn Sie bei API-Anwendungen einen HTTP-Protokollstatuscode angeben, wenn die Geschäftslogik fehlschlägt, wird unter der Annahme, dass die API für Front-End-Ajax gedacht ist, nur ein Fehler im Konsolenprotokoll ausgegeben. Wenn Sie von jquery verarbeitetes Ajax verwenden, wird der Rückruf der Fehlerfunktion ausgelöst. Der normale Ansatz besteht darin, JSON-Daten zurückzugeben, wenn das Fehlerinformationsfeld angezeigt wird in json wird angezeigt. Wenn Sie beim Auftreten eines Fehlers den Rückkehrcode verwenden, können Sie die spezifische Fehlerursache im Fehlerrückruf nicht ermitteln. Sie können nur eine vage Meldung anzeigen, dass in Operation xxx ein Fehler aufgetreten ist. Dies ist definitiv nicht das, was der Benutzer möchte Dies erhöht auch die Schwierigkeit, dass Benutzer ein Problem nur vage beschreiben können, wenn sie es dem Kundendienst schildern. Natürlich gibt es ein verstecktes Problem. Wenn Sie einen Reverse-Proxy verwenden, kann das Front-End-Programm nicht unterscheiden, ob der aktuelle ungültige Rückkehrcode von der Webanwendung oder dem Reverse-Proxy-Server zurückgegeben wird.

Angenommen, Sie verwenden benutzerdefinierte HTTP-Rückgabecodes zwischen APIs und reinen Servern, werden Sie feststellen, dass es für Entwickler nicht ausreicht, nur einen HTTP-Rückgabecode zu analysieren. Sie möchten die Details des Fehlers wissen um A-JSON-Daten zurückzugeben. Natürlich besteht hier weiterhin das oben erwähnte Reverse-Proxy-Problem.

Zusammenfassend lässt sich sagen, dass ich die Verwendung benutzerdefinierter HTTP-Rückgabecodes nicht empfehle. Obwohl dies wissenschaftlich ist, ist es zu akademisch und unpraktisch. Insbesondere bei Website-Anwendungen wird 404 oder 500 zurückgegeben, wenn ein Link nicht gefunden werden kann oder eine nicht erfasste Ausnahme auftritt, und bei der Rückgabe sollte eine benutzerfreundliche Fehlerseite verwendet werden. Andere logische Fehler sollten ebenfalls von Fehlerseiten übertragen werden möglich.

422 Nicht verarbeitbare Entität – [POST/PUT/PATCH] Beim Erstellen eines Objekts ist ein Validierungsfehler aufgetreten.

Das fühlt sich angemessen an

422 Nicht verarbeitbare Entität – [POST/PUT/PATCH] Beim Erstellen eines Objekts ist ein Validierungsfehler aufgetreten.

Dieser Tipp ist auch gut

Wenn es widersprüchliche Informationen gibt, können Sie auch 409-Konflikt verwenden

Sie können sich die HTTP-Statuscode-Analyse hier ansehen
http://jingyan.baidu.com/arti...