Die ultimative Referenz für HTTP-Statuscodes im API-Design

In der Welt der Webentwicklung und des API-Designs spielen HTTP-Statuscodes eine entscheidende Rolle bei der Kommunikation des Ergebnisses von Anfragen zwischen Clients und Servern. Diese Codes bieten eine standardisierte Möglichkeit, bestimmte Bedingungen, Erfolge oder Fehler anzuzeigen, die während der Verarbeitung von HTTP-Anfragen auftreten. Das Verständnis dieser Statuscodes ist für Entwickler von entscheidender Bedeutung, da es beim Debuggen, der Fehlerbehandlung und der Erstellung robusterer Anwendungen hilft.

1. 1xx Information

Diese Statuscodes weisen auf eine vorläufige Antwort hin. Sie werden in der Praxis selten verwendet, können aber in bestimmten Situationen hilfreich sein.

• 100 Weiter: Der Server hat die Anforderungsheader empfangen und der Client sollte mit dem Senden des Anforderungstexts fortfahren.
• 101 Protokollwechsel: Der Anforderer hat den Server gebeten, das Protokoll zu wechseln, und der Server hat dem zugestimmt.

2. 2xx Erfolg

Diese Statuscodes zeigen an, dass die Anfrage des Kunden erfolgreich empfangen, verstanden und angenommen wurde.

• 200 OK: Die Anfrage war erfolgreich und die Antwort enthält die angeforderten Daten oder das angeforderte Ergebnis.
  • Beispiel: Abrufen der Profilinformationen eines Benutzers.
• 201 erstellt: Die Anfrage war erfolgreich und eine neue Ressource wurde erstellt.
  • Beispiel: Erstellen eines neuen Benutzerkontos oder Veröffentlichen eines neuen Blogeintrags.
• 204 Kein Inhalt: Der Server hat die Anfrage erfolgreich verarbeitet, gibt aber keinen Inhalt zurück.
  • Beispiel: Aktualisieren der Einstellungen eines Benutzers, bei dem kein Antworttext erforderlich ist.
• 206 Teilinhalt: Der Server stellt aufgrund eines vom Client gesendeten Bereichsheaders nur einen Teil der Ressource bereit.
  • Beispiel: Videoinhalte streamen oder große Dateien in Blöcken herunterladen.

3. 3xx-Umleitung

Diese Statuscodes weisen darauf hin, dass der Benutzeragent weitere Maßnahmen ergreifen muss, um die Anfrage zu erfüllen.

• 301 Permanent verschoben: Die angeforderte Ressource wurde dauerhaft an eine neue URL verschoben.
• 302 gefunden: Die angeforderte Ressource befindet sich vorübergehend unter einer anderen URL.
• 304 Not Modified: Zeigt an, dass die Ressource seit der in den Anforderungsheadern angegebenen Version nicht geändert wurde.

4. 4xx-Client-Fehler

Diese Statuscodes sind für Situationen gedacht, in denen der Kunde offenbar einen Fehler gemacht hat.

• 400 Bad Request: Der Server kann die Anfrage aufgrund ungültiger Syntax oder fehlerhafter Eingabe nicht verarbeiten.

  • Beispiel: Senden eines fehlerhaften JSON-Codes im Anforderungstext.
  • Verwendung: Wird verwendet, wenn die Anfrage selbst fehlerhaft ist oder ungültige Parameter enthält.

• 401 Nicht autorisiert: Die Anfrage erfordert eine Benutzerauthentifizierung.

  • Beispiel: Versuch, auf einen geschützten API-Endpunkt zuzugreifen, ohne gültige Anmeldeinformationen anzugeben.
  • Verwendung: Wird verwendet, wenn eine Authentifizierung erforderlich ist und nicht bereitgestellt wurde oder ungültig ist.

• 403 Verboten: Der Server versteht die Anfrage, weigert sich jedoch, sie zu autorisieren.

  • Beispiel: Ein Benutzer versucht, auf Funktionen zuzugreifen, die nur Administratoren vorbehalten sind.
  • Verwendung: Wird verwendet, wenn der Benutzer authentifiziert ist, aber keine Berechtigung für den angeforderten Vorgang hat.

• 404 Not Found: Die angeforderte Ressource konnte nicht auf dem Server gefunden werden.

  • Beispiel: Versuch, ein gelöschtes Benutzerprofil abzurufen.
  • Verwendung: Wird verwendet, wenn die angeforderte Ressource nicht vorhanden ist.

• 405-Methode nicht zulässig: Die in der Anfrage angegebene Methode ist für die durch den Anfrage-URI identifizierte Ressource nicht zulässig.

  • Beispiel: Senden einer POST-Anfrage an einen Endpunkt, der nur GET-Anfragen akzeptiert.

• 409-Konflikt: Die Anfrage konnte aufgrund eines Konflikts mit dem aktuellen Status der Ressource nicht verarbeitet werden.

  • Beispiel: Es wird versucht, einen Benutzer mit einer E-Mail-Adresse zu erstellen, die bereits im System vorhanden ist.
  • Verwendung: Wird verwendet, wenn ein Konflikt mit dem aktuellen Status der Ressource besteht, beispielsweise doppelte Einträge.

• 422 Unprocessable Entity: Der Server versteht den Inhaltstyp und die Syntax der Anfrage, kann die enthaltenen Anweisungen jedoch nicht verarbeiten.

  • Beispiel: Senden eines Formulars mit ungültigen Daten, die die serverseitige Validierung nicht bestehen.
  • Verwendung: Wird für Validierungsfehler verwendet, bei denen die Anforderungssyntax korrekt ist, die Daten jedoch semantisch falsch sind.

• 429 Zu viele Anfragen: Der Benutzer hat in einem bestimmten Zeitraum zu viele Anfragen gesendet („Ratenbegrenzung“).

  • Beispiel: Implementierung einer API-Ratenbegrenzung, um Missbrauch zu verhindern.

5. 5xx-Serverfehler

Diese Statuscodes weisen auf Fälle hin, in denen der Server weiß, dass ein Fehler aufgetreten ist oder er aus anderen Gründen nicht in der Lage ist, die Anfrage auszuführen.

• 500 Interner Serverfehler: Eine allgemeine Fehlermeldung, die darauf hinweist, dass der Server auf einen unerwarteten Zustand gestoßen ist, der die Erfüllung der Anforderung verhindert hat.

  • Beispiel: Im serverseitigen Code tritt eine nicht behandelte Ausnahme auf.

• 501 nicht implementiert: Der Server unterstützt nicht die zur Erfüllung der Anfrage erforderliche Funktionalität.

  • Beispiel: Verwendung einer neuen HTTP-Methode, die der Server nicht erkennt.

• 502 Bad Gateway: Der Server hat, während er als Gateway oder Proxy fungierte, eine ungültige Antwort vom Upstream-Server erhalten.

  • Beispiel: Ein Reverse-Proxy-Server kann keine Verbindung zum Ursprungsserver herstellen.

• 503 Dienst nicht verfügbar: Der Server kann die Anfrage derzeit aufgrund vorübergehender Überlastung oder Wartungsarbeiten nicht verarbeiten.

  • Beispiel: Ein Server wird regelmäßig gewartet oder es herrscht hoher Datenverkehr.

• 504 Gateway Timeout: Der Server, der als Gateway oder Proxy fungiert, hat keine rechtzeitige Antwort vom Upstream-Server erhalten.

  • Beispiel: Beim Warten auf eine Antwort von einer Drittanbieter-API tritt eine Zeitüberschreitung auf.

Best Practices für die Verwendung von HTTP-Statuscodes

1. Seien Sie genau: Verwenden Sie den spezifischsten Statuscode, der auf die Situation zutrifft. Dies hilft Kunden, genau zu verstehen, was passiert ist und wie sie reagieren sollen.

2. Konsistente Nutzung: Sorgen Sie für Konsistenz bei der Verwendung von Statuscodes in Ihrer gesamten API. Dies erleichtert Entwicklern die Arbeit mit Ihrer API.

3. Geben Sie zusätzliche Informationen an: Fügen Sie zusammen mit dem Statuscode gegebenenfalls eine detaillierte Fehlermeldung in den Antworttext ein. Dies kann beim Debuggen helfen und das Entwicklererlebnis verbessern.

4. Sicherheitsüberlegungen: Seien Sie vorsichtig, wenn Sie nicht zu viele Informationen in Fehlerantworten preisgeben, insbesondere bei 4xx- und 5xx-Fehlern. Vermeiden Sie es, sensible Details über Ihre Systemarchitektur oder -implementierung preiszugeben.

5. Dokumentation: Dokumentieren Sie klar und deutlich, welche Statuscodes Ihre API unter welchen Umständen verwendet. Dies hilft API-Konsumenten zu verstehen, wie sie unterschiedliche Antworten interpretieren und verarbeiten.

Durch das Verständnis und die richtige Implementierung von HTTP-Statuscodes können Entwickler robustere, klarere und benutzerfreundlichere APIs und Webanwendungen erstellen. Diese Codes dienen als wichtiges Kommunikationstool zwischen Clients und Servern und tragen dazu bei, die Fehlerbehandlung zu rationalisieren und die allgemeine Systemzuverlässigkeit zu verbessern.

Das obige ist der detaillierte Inhalt vonDie ultimative Referenz für HTTP-Statuscodes im API-Design. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!