Ich bin auf der Suche nach Leitlinien für bewährte Praktiken, wenn es darum geht, Fehler von einer REST-API zurückzugeben. Ich arbeite an einer neuen API, so dass ich sie im Moment in jede Richtung verwenden kann. Mein Inhaltstyp ist im Moment XML, aber ich plane, in Zukunft JSON zu unterstützen.
Ich füge jetzt einige Fehlerfälle hinzu, z. B. wenn ein Kunde versucht, eine neue Ressource hinzuzufügen, aber sein Speicherkontingent überschritten hat. Ich behandle bereits bestimmte Fehlerfälle mit HTTP-Statuscodes (401 für Authentifizierung, 403 für Autorisierung und 404 für fehlerhafte Anfrage-URIs). Ich habe mir die gesegneten HTTP-Fehlercodes angesehen, aber keiner der Codes zwischen 400 und 417 scheint geeignet, anwendungsspezifische Fehler zu melden. Zuerst war ich versucht, meinen Anwendungsfehler mit 200 OK und einer spezifischen XML-Nutzlast zurückzugeben (z. B. Zahlen Sie uns mehr und Sie bekommen den Speicherplatz, den Sie brauchen!), aber ich habe darüber nachgedacht und es scheint mir zu seifig zu sein (/Achselzucken vor Entsetzen). Außerdem fühlt es sich so an, als würde ich die Fehlerantworten in verschiedene Fälle aufteilen, da einige durch den http-Statuscode und andere durch den Inhalt bestimmt sind.
Wie lauten also die Empfehlungen der Industrie? Bewährte Praktiken (bitte erläutern Sie, warum!) und auch, aus Kundensicht, welche Art der Fehlerbehandlung in der REST-API macht das Leben für den Client-Code einfacher?
7 Stimmen
Nur um das klarzustellen: Ich bin nicht so sehr daran interessiert, welcher HTTP-Statuscode zurückgegeben werden soll, sondern ob es eine gute REST-Praxis ist, Payload-Fehler mit HTTP-Statuscodes zu kombinieren, oder ob es besser ist, sich ausschließlich auf die Payload zu verlassen.
3 Stimmen
Das REST-API-Entwurfshandbuch behandelt dieses Thema sehr gut.
22 Stimmen
In der Frage wird nicht nach einer Meinung gefragt, sondern nach Leitlinien/Empfehlungen, und sie sollte erneut geöffnet und als Referenz verwendet werden. Welchen Sinn hat es, 2016 eine Frage zu schließen, die 2009 erstellt wurde, über 400 Stimmen hat und keine der vorhandenen Antworten auf Meinungen basiert?
5 Stimmen
Die meisten haben es nicht erwähnt, aber die Verwendung der HTTP-Fehlercodes kann zu Problemen bei der Ermittlung der Hauptursache eines Problems führen. HTTP ist das Transportprotokoll und ein 404 sollte anzeigen, dass es ein Problem mit der URL auf Transportebene gab (z. B. ein falscher Pfad). Wenn die Anwendung einen Datensatz nicht anhand seiner ID finden kann, ist dies ein Fehler auf Anwendungsebene (und nicht auf Transportebene), und ein 404, wie von den Nutzern von restful http status code vorgeschlagen, könnte zu einer falschen Schlussfolgerung führen. Generell gefällt mir die Verwechslung von Transport- und Anwendungsebene bei der Verwendung der Statuscodes nicht.
0 Stimmen
Siehe eine andere Antwort zu einem ähnlichen Thema: stackoverflow.com/a/63046962/2153237