it-swarm.com.de

Richtige Statuscodes für JSON-Antworten auf Ajax-Aufrufe?

Mein Projekt gibt JSON an Ajax-Aufrufe vom Browser zurück. Ich frage mich, wie der richtige Statuscode für das Zurücksenden von Antworten auf ungültige (aber erfolgreich verarbeitete) Datenübermittlungen lautet.

Zum Beispiel hat jQuery die folgenden zwei besonderen Rückrufe, wenn Ajax-Anfragen gestellt werden:

success: Wird ausgelöst, wenn zusammen mit der Antwort ein 200/2xx-Statuscode übermittelt wird.

error: Wird ausgelöst, wenn 4xx, 5xx usw. Statuscodes mit der Antwort zurückkommen.

Wenn ein Benutzer versucht, ein neues "Personen" -Objekt zu erstellen, sende ich bei Erfolg eine JSON-Darstellung des neu erstellten Objekts zurück, wodurch Javascript auf die erforderlichen eindeutigen IDs für das neue Objekt usw. zugreifen kann. Dies wird natürlich gesendet mit einem 200-Statuscode.

Wenn ein Benutzer fehlerhafte oder ungültige Daten übermittelt (z. B. ein ungültiges/unvollständiges "Name" -Feld), möchte ich die Überprüfungsfehlermeldungen über JSON zurücksenden. (Ich verstehe nicht, warum das eine schlechte Sache wäre).

Meine Frage lautet: Soll ich dabei einen 200 - Statuscode senden, weil ich ihre ungültigen Daten erfolgreich verarbeitet habe? Daher würde ich den Callback für jQuery success verwenden, aber einfach nach Fehlern suchen ...

Oder , sollte ich einen 4xx Statuscode verwenden, vielleicht 'Bad Request', weil die von ihnen gesendeten Daten ungültig sind? (Verwenden Sie daher den Rückruf error, um die erforderlichen clientseitigen Benachrichtigungen durchzuführen.).

28

Ich stimme der 400 Bad Request-Antwort zu. 

Als Inspiration können Sie einen Blick darauf werfen, wie Twitter (der weit verbreitete JSON-Dienst) Folgendes tut: https://dev.Twitter.com/overview/api/response-codes

CodeText Beschreibung

  • 200OK - Erfolg! 
  • 304Not Modified - Es wurden keine neuen Daten zurückgegeben. 
  • 400Bad Request - Die Anforderung war ungültig oder kann nicht anderweitig geliefert werden. Eine begleitende Fehlermeldung wird weiter erläutert. Anfragen ohne Authentifizierung werden als ungültig betrachtet und geben diese Antwort ab. 
  • 401Unauthorized - Fehlende oder falsche Authentifizierungsinformationen. Wird auch unter anderen Umständen zurückgegeben (z. B. geben alle Aufrufe von API-v1-Endpunkten 401 zurück). 
  • 403Forbidden - Die Anfrage wird verstanden, aber abgelehnt oder der Zugriff ist nicht zulässig. Eine begleitende Fehlermeldung erklärt, warum. Dieser Code wird verwendet, wenn Anforderungen aufgrund von Aktualisierungslimits abgelehnt werden. Andere Gründe für die Rückgabe dieses Status sind neben den Antwortcodes in der nachstehenden Tabelle aufgeführt. 
  • 404Not Found - Der angeforderte URI ist ungültig oder die angeforderte Ressource, z. B. ein Benutzer, ist nicht vorhanden. Wird auch zurückgegeben, wenn das angeforderte Format von der angeforderten Methode nicht unterstützt wird. 
  • 406Not Acceptable - Wird zurückgegeben, wenn in der Anforderung ein ungültiges Format angegeben wurde. 
  • 410Gone - Diese Ressource ist weg. Wird verwendet, um anzuzeigen, dass ein API-Endpunkt deaktiviert wurde. 
  • 420Enhance Your Calm Wird zurückgegeben, wenn für eine Anwendung die Rate begrenzt ist. 
  • 422Unprocessable Entity - Wird zurückgegeben, wenn ein in POST account/update_profile_banner hochgeladenes Bild nicht verarbeitet werden kann. 
  • 429Too Many Requests - Wird zurückgegeben, wenn eine Anforderung nicht zugestellt werden kann, da die Ratenbegrenzung der Anwendung für die Ressource erschöpft ist. Siehe Preisbegrenzung. 
  • 500Internal Server Error = Etwas ist defekt. Bitte senden Sie an die Entwicklerforen mit zusätzlichen Details Ihrer Anfrage, falls andere ähnliche Probleme haben. 
  • 502Bad Gateway - Twitter ist inaktiv oder wird aktualisiert. 
  • 503Service Unavailable - Die Twitter-Server sind in Betrieb, jedoch mit Anfragen überlastet. Versuchen Sie es später noch einmal. 
  • 504Gateway Timeout - Die Twitter-Server sind in Betrieb, die Anforderung konnte jedoch aufgrund eines Fehlers in unserem Stack nicht bearbeitet werden. Versuchen Sie es später noch einmal.
14
MPV

Ich würde einen "400 Bad Request" -Header als Antwort mit Informationen in json zurückschicken, was falsch gelaufen ist. Dann fangen Sie das Ereignis mit jquerys $ .ajaxError () - Ereignishandler ab und analysieren die Fehlermeldung, zu der ich zurückgekehrt bin Geben Sie dem Endbenutzer gutes Feedback.

Weitere Informationen zum ajaxError-Ereignishandler hier

1
Wirde