Statuscode "Ungültiger Vorgang" in einer HATEOAS REST-API


8

In einer HATEOAS-API werden Links zurückgegeben, die mögliche Zustandsübergänge darstellen. Ein konformer Client sollte nur diese Links abrufen und befolgen. Wenn jedoch ein nicht konformer Client URIs erstellt, anstatt den angegebenen Links zu folgen, welcher Statuscode / welche Antwort ist am besten geeignet, um zurückzukehren?

  • 400 würde funktionieren, zusammen mit einigen Informationen im Antworttext - das ist, was wir derzeit tun
  • 403 Ich denke, das wäre falsch, da dies impliziert, dass die Anfrage niemals funktionieren könnte - aber möglicherweise ist der Link in Zukunft verfügbar
  • 404 klingt plausibel - zu diesem Zeitpunkt existiert die Ressource nicht

Was denken die Leute? Ich weiß, dass bedingte Anforderungen Anforderungen verarbeiten können, die auf veralteten Antworten basieren (was z. B. 412 Sekunden ergibt), aber dies ist eine etwas andere Situation.

Aktualisieren:

OK, ich sehe jetzt, dass die richtige Antwort für diese Arten von ungültigen Vorgängen eine 404 wäre. Wie wäre es, wenn die Syntax einer Anfrage korrekt ist, sie zu einer gültigen Ressource geht, aber irgendwie gegen eine Geschäftsregel verstößt. Hier sind einige erfundene Beispiele:

  1. Angenommen, der Client kann zwei Zahlen angeben, die innerhalb von 20% voneinander liegen müssen, andernfalls kann es sich um eine beliebige Zahl handeln.
  2. Angenommen, der Client kann eine Nummer angeben, die eine Berechnung durchläuft, deren Ergebnis darauf hinweist, dass die ursprünglich angegebene Nummer falsch war.

Ist 400 die richtige Antwort für diese?


Antworten:


5

Wenn die Möglichkeit besteht, dass die Links in Zukunft vorhanden sind, sind sowohl 400 Bad Request als auch 403 Forbidden falsch: Die entsprechenden Abschnitte in RFC 2616 enthalten Anweisungen, dass der Client die Anforderung NICHT wiederholen soll. Der Unterschied zwischen den beiden besteht darin, dass der Server im Fall von 400 Bad Request nicht verstanden hat, was der Client versucht hat, während der Server bei 403 Forbidden die Anfrage verstanden hat, sich jedoch (jemals) weigert, sie zu erfüllen.

Wenn Sie dem Kunden mitteilen möchten, dass die Anforderung verstanden wurde, Sie sie jedoch zum Zeitpunkt der Anforderung nicht bearbeiten (aber keinen Anspruch auf zukünftige Bearbeitung erheben), ist 404 Not Found die am besten geeignete Antwort senden.

Wenn Sie an den Client , um anzuzeigen , möchten , dass Anforderung verstanden wurde, aber der Antrag folgt nicht vorgegebenen Regeln oder Richtlinien (wie Ihr Beispiel für ein Client nicht die Bereitstellung von zwei Zahlen innerhalb von 20% voneinander), die Sie verwenden möchten 409 Conflict , die soll dem Client anzeigen, dass die Anforderung behoben werden muss, um ordnungsgemäß behandelt zu werden.

Sie sollten jedoch die Nichtkonformität in gutem Glauben von der Nichtkonformität in schlechtem Glauben trennen. Wenn Sie versuchen, Ihre Anwendung vor Anfragen eines schlechten Schauspielers zu schützen, ist es ihnen mit ziemlicher Sicherheit egal, welchen Antwortcode Sie senden: Sie erstellen nur so lange URLs, bis sie auf etwas stoßen, das ihnen gefällt.


OK, ich denke, das bringt die Frage auf den Punkt. Ich habe es ein wenig erweitert, um einen größeren Bereich ungültiger Operationen abzudecken - vermutlich ist für diese 400 die richtige Antwort?
FinnNk

@FinnNk Nein, 400 Bad Request ist nur, wenn der Server nicht verstehen kann, was der Client überhaupt versucht hat. Wenn die Anfrage verstanden wurde, der Inhalt der Anfrage jedoch ungültig ist, möchten Sie mit 409 Conflict antworten.

2

Diese Codes folgen dem vom HTTP-RFC festgelegten Standard .

Gemäß dem Abschnitt Statuscode-Definitionen :

  • 400 schlechte Anfrage

Die Anforderung konnte vom Server aufgrund einer fehlerhaften Syntax nicht verstanden werden. Der Client sollte die Anfrage NICHT ohne Änderungen wiederholen.

  • 403 Verboten

Der Server hat die Anfrage verstanden, weigert sich jedoch, sie zu erfüllen. Die Autorisierung hilft nicht und die Anfrage sollte nicht wiederholt werden. Wenn die Anforderungsmethode nicht HEAD war und der Server veröffentlichen möchte, warum die Anforderung nicht erfüllt wurde, sollte der Grund für die Ablehnung in der Entität beschrieben werden. Wenn der Server diese Informationen dem Client nicht zur Verfügung stellen möchte, kann stattdessen der Statuscode 404 (Nicht gefunden) verwendet werden.

  • 404 Nicht gefunden

Der Server hat nichts gefunden, das mit dem Request-URI übereinstimmt. Es wird kein Hinweis darauf gegeben, ob der Zustand vorübergehend oder dauerhaft ist. Der Statuscode 410 (Gone) sollte verwendet werden, wenn der Server über einen intern konfigurierbaren Mechanismus weiß, dass eine alte Ressource dauerhaft nicht verfügbar ist und keine Weiterleitungsadresse hat. Dieser Statuscode wird häufig verwendet, wenn der Server nicht genau angeben möchte, warum die Anforderung abgelehnt wurde, oder wenn keine andere Antwort zutreffend ist.

In Ihrem Fall wäre es meiner Meinung nach angebracht, 404 zurückzugeben , wenn der erstellte URI nirgendwohin führt .

Und wenn der URI gültig ist, aber die übergebenen Daten (wie ein JSON-Dokument) fehlerhaft sind , sollten Sie 400 zurückgeben .

BEARBEITEN :

Beantwortung des OP-Kommentars: Ich denke, das System sollte 400 zurückgeben, wenn die Syntax und auch die Bedeutung der Daten fehlerhaft sind.


Meinen Sie mit kaputt im Kontext einer REST-API nur die Syntax oder enthält sie auch die Bedeutung der Daten? Weitere Informationen finden Sie in der erweiterten Frage.
FinnNk

Beide Fälle sollten meiner bescheidenen Meinung nach 400 ergeben.
Karlphillip

Ich habe Ihre Antwort akzeptiert, aber können Sie Ihren Kommentar in den Antworttext verschieben? Prost.
FinnNk

Beim erneuten Lesen des HTTP-RFC ist Marks weitere Antwort sehr sinnvoll, daher habe ich die akzeptierte Antwort geändert. Ich muss sagen, dass es eine Kombination Ihrer beiden Antworten war, die mein Verständnis hier vertieft hat.
FinnNk
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.