Angenommen, der Client sendet eine Anfrage an den Server. Nach der Überprüfung der Daten stellt der Server fest, dass sie nicht mit den Daten übereinstimmen, und muss einen Fehler zurückgeben.

Nach meinem Verständnis ist der Anforderungsprozess des Clients korrekt. Selbst wenn das Datenformat nicht den Anforderungen des Servers entspricht, sollte der Server einen Statuscode 200 zurückgeben und dann eine Fehlermeldung oder einen Bericht im JSON-Format zurückgeben Geben Sie den Text der Nachricht ein und hängen Sie dann den tatsächlichen Statuscode an die Nachricht an.

Aber nachdem sie sich die Schnittstellen einiger anderer Leute angesehen hatten, gaben einige Leute direkt den Statuscode 510 zurück.

Entschuldigung, was denken Sie? Was ist die Norm?

Antwortinhalt:

Angenommen, der Client sendet eine Anfrage an den Server. Nach der Überprüfung der Daten stellt der Server fest, dass sie nicht mit den Daten übereinstimmen, und muss einen Fehler zurückgeben.

Aber nachdem sie sich die Schnittstellen einiger anderer Leute angesehen hatten, gaben einige Leute direkt den Statuscode 510 zurück.

Entschuldigung, was denken Sie? Was ist die Norm?

Viele der Schnittstellen im Internet sind größtenteils nicht konform. Um es ganz klar auszudrücken: Es handelt sich um HTTP-Dienste, die von einer Gruppe von Leuten geschrieben wurden, die das HTTP-Protokoll nicht einmal verstehen. Also verweilen Sie nicht dabei. Der Grund, warum PHP Hacker anzieht, ist ein ähnlicher Grund. Ich bin sehr dankbar, dass Sie bereit sind, sich mit diesem Thema zu befassen. Ich muss Sie für Ihren Geist loben.

Tatsächlich empfehle ich Ihnen den Kauf dieses Buches: „The Definitive Guide to HTTP“, das für motivierte Menschen wie Sie sehr gut geeignet ist.

Tatsächlich ist Ihr Verständnis dieses Problems voreingenommen.

Nur weil der Anfrageprozess korrekt ist, heißt das nicht, dass die Antwort 200 sein sollte. Da Sie eine Antwort erhalten können, bedeutet dies, dass kein Problem mit dem Anforderungsprozess vorliegt . Wenn der Anforderungsprozess fehlerhaft ist, liegt entweder eine DNS-Ausnahme oder ein Verbindungszeitlimit usw. vor. Sie können den Antwortcode „Angekommen“ nicht einmal sehen.

Der Antwortcode wird also verwendet, um das Ergebnis zu identifizieren, das der HTTP-Server als Antwort auf die Anfrage liefert.

Aus diesem Grund hauptsächlich werden diejenigen, die mit 2 beginnen, definitiv erfolgreich sein (nicht nur 200), und diejenigen, die mit 3 beginnen, sind normalerweise keine Ausnahme, aber Möglicherweise wird die Ressource nicht direkt aus Ihrer Anfrage abgerufen, z. B. 302-Umleitung, 304-Cache ist nicht abgelaufen usw.

Hier ist der entscheidende Punkt: Zahlen, die mit 4 beginnen, bedeuten oft, dass es Ausnahmen in der Anfrage gibt, z. B. das sogenannte übermittelte Datenformat ist falsch 400 oder 422, die Anfrage erfordert aus irgendeinem Grund (unzureichende Berechtigungen) die Autorisierung 401 oder Blacklist) Verwenden Sie 403 zum Ablehnen, verwenden Sie 404, wenn die angeforderten Daten nicht vorhanden sind oder die Daten nicht durch die aktuelle Anforderung abgerufen werden sollen (sehr bekannt), verwenden Sie 405, wenn die Anforderungsmethode beispielsweise abgelehnt wird, sollten Sie verwenden PUT zum Ändern von Daten, POST zum Hinzufügen von Daten und GET zum Abrufen von Daten. Verwenden Sie DELETE-Anforderungen zum Löschen von Daten usw. (Am häufigsten sind natürlich auch OPTIONS- und HEAD-Anforderungen vorhanden). Ausführliche Artikel zu HTTP-Statuscodes finden Sie in der Enzyklopädie (egal in welcher Enzyklopädie).

Dinge, die mit 5 beginnen, sind hauptsächlich Serverfehler, die nicht durch Anforderungsfehler verursacht werden. Dies sind alle Statuscodes, die mit 5 beginnen, wie z. B. 500 Server Exception und 503 Server Unable to Provide Service.

Der HTTP-Statuscode ist in einer Reihe von RFC-Standarddokumenten definiert und kann daher nicht vollständig an alle Eingabeaufforderungsdetails der Schnittstelle angepasst werden, kann aber die Semantik der meisten Antworten vollständig abdecken. Für detaillierte Eingabeaufforderungen wird häufig ein separater Statusantwortcode in der Schnittstellenantwort festgelegt, um die mangelnde Aussagekraft von HTTP-Statuscodes für detaillierte Probleme auszugleichen. Beispielsweise ist das Anforderungsformat falsch, aber ein bestimmter Parameter fehlt oder es werden zu viele Parameter angegeben, und beide sind 400. Wenn Sie möchten, dass der Client klar weiß, was passiert ist, müssen Sie in der Schnittstelle etwas Zusätzliches definieren, um ihn zu unterstützen so eine Situation.

Diese Frage muss tatsächlich mit konkreten Anwendungsszenarien kombiniert werden.

Wenn sich Ihr Kunde auf eine App bezieht, insbesondere auf eine mobile App, ist die Verwendung von 200 plus einem bestimmten Fehlercode die richtige Wahl! Das ist nicht vernünftiger, aber in China (naja, eigentlich gibt es auch andere Länder) gibt es eine nationale Bedingung namens HTTP-Hijacking. 404 oder 500 können direkt vom Betreiber oder anderen gekapert werden (haha). Die von Ihnen zurückgegebenen zusätzlichen HTTP-Fehlerinformationen werden von der App nicht empfangen. Wenn Sie sich also die öffentlichen Netzwerkprotokolle von Fabrik A, Fabrik B und Fabrik T ansehen, werden sie alle Fehler auf diese Weise übertragen. Es ist nicht so, dass Designer oder Architekten nicht verstehen, was Restful- und HTTP-Statuscodes sind.

Wenn es sich um ein internes Protokoll handelt, Dienst für Dienst, und die Umgebung garantiert ist, können Sie Fehler in einer standardmäßigen, erholsamen Form definieren.

Oh, teilen Sie Ihr Bild, wenn Sie die Voraussetzungen erfüllen und das Fehlerprotokoll in Form von Standard-HTTP-Statuscodes bevorzugen.
Problem mit der Spezifikation des HTTP-Protokoll-Rückgabestatuscodes

Jede Spezifikation hat ihre eigenen Gründe. Die beiden von Ihnen erwähnten Statuscodes verwenden zum einen die HTTP-Anfrage als Hauptreferenz zur Analyse des Statuscodes und zum anderen ist die eigene Schnittstelle die Hauptreferenz zur Analyse des Statuscodes . Beides hat seine eigenen Gründe, es hängt vom Nutzungsszenario ab

Ist es standardisiert? Oder folgen Sie dem Beispiel des Unternehmens ~ Ich persönlich bevorzuge die Verwendung von HTTP-Statuscodes, um Fehler zurückzugeben und Fehlermeldungen zu übermitteln.

Ihrer ist zwar nicht der 200-Statuscode, aber die anderen Statuscodes können auch entsprechenden Inhalt oder JSON haben. Ich weiß nicht, ob Sie Spring MVC jemals verwendet haben . Diese Funktion gibt einen 400-Statuscode und einen JSON-Code zurück, sofern dieser zur Überprüfung verwendet wird.

Das hängt davon ab, wie Ihr Projekt reguliert ist! Sie können der http-Methode folgen oder sie selbst einrichten! Wenn Sie beispielsweise diesen Fehlerstatuscode erhalten, legen Sie selbst einen neuen Statuscode fest und geben Sie dann einige Informationsaufforderungen zurück!

Es hängt von den Anforderungen ab. Auch wenn Sie das Projekt persönlich leiten, können Sie sich durchsetzen

Weitere Informationen finden Sie in der WeChat-Entwicklungsdokumentation von Tencent.
Es handelt sich bei allen um einheitliche Schnittstellen-Rückgabewerte.
Der HTTP-Statuscode lautet grundsätzlich 200.
Verwenden Sie unterschiedliche Fehlercodes, um Fehler zu definieren.

Persönliche Meinung

Es ist korrekt, den HTTP-Statuscode zu verwenden.

510 Ich verstehe nicht, nennen Sie mir einen Statuscode, den ich oft schreibe.

http-Status 400 und 403.

Ersteres bedeutet, dass die Anforderung nicht analysiert werden kann. Dies liegt normalerweise daran, dass ein Problem mit den Parametern vorliegt. In den meisten Fällen ist für diesen Fehler kein Schreiben von Code zur Beurteilung erforderlich. Das Serverprogramm beurteilt dies automatisch und gibt ihn zurück Status.

Mein Parameter erlaubt beispielsweise nur die Übergabe von Zahlen zwischen 1 und 10. Wenn der Benutzer einen zufälligen Pass durchführt, werde ich diesen Statuscode zurückgeben.

Letzteres bedeutet, dass der Benutzer keine Zugriffsberechtigung hat. Zusätzlich zu einigen in der Konfiguration festgelegten verbotenen Zugriffspfaden erfordert dieser Fehler häufig das Schreiben von Code zur Ermittlung der Berechtigungen.

Zum Beispiel erlaubt mein Backend nur den Zugriff von bestimmten IPs und Maschinen mit bestimmten Anforderungsheadern, und alle anderen Maschinen geben diesen Statuscode zurück.

Wenn Sie 200 JSON verwenden, um den Statuscode zurückzugeben, ist die Bedeutung dieser Standard-HTTP-Statuscodes grundsätzlich nutzlos. Der Designer hatte es bereits auf nur 200 und 404 vereinfacht. Sogar 404 kann den JSON-Statuscode verwenden, verwenden Sie einfach 200, um anzuzeigen, ob eine Verbindung besteht oder nicht.

Was sind die Vorteile von Statuscodes?

Moderne Browser und Suchmaschinen-Crawler erkennen und verarbeiten teilweise HTTP-Statuscodes

Zum Beispiel:

Der Statuscode 4xx bedeutet, dass die aktuelle URL falsch ist, es macht keinen Sinn, die Anfrage erneut zu senden.
Wenn eine Ihrer Seiten http 200 json 400 zurückgibt, bedeutet das, dass etwas mit ihren Parametern nicht stimmt.

Die Suchmaschine analysiert Ihren benutzerdefinierten Statuscode nicht und schließt diese Daten natürlich fälschlicherweise ein.
Einige Benutzer springen über Suchmaschinen zu Seiten mit falschen Parametern.

Der Browser analysiert Ihren benutzerdefinierten Statuscode auch nicht. Der Browser zeichnet Ihre Zugriffsdatensätze automatisch auf und der Browser empfängt Status wie 400, 403 und 404. Der Code wird nicht analysiert Browserverlauf speichern (dies ist bei Chrome der Fall und scheint bei anderen ähnlich zu sein) .

Nachdem Sie 200 zurückgegeben haben, besteht eine hohe Wahrscheinlichkeit, dass der Benutzer bei der Eingabe der URL auf den Eingabeaufforderungsdatensatz des Browsers klickt und dadurch erneut auf die falsche Verbindung zugreift.