wake-up-neo.com

Ist es falsch, 202 "Accepted" als Antwort auf HTTP GET zurückzugeben?

Ich habe eine Reihe von Ressourcen, deren Repräsentationen faul erstellt werden. Die Berechnung zum Erstellen dieser Repräsentationen kann je nach Serverlast, der jeweiligen Ressource und der Mondphase zwischen wenigen Millisekunden und einigen Stunden dauern.

Die erste GET-Anforderung für die Ressource startet die Berechnung auf dem Server. Wenn die Berechnung innerhalb weniger Sekunden abgeschlossen ist, wird die berechnete Darstellung zurückgegeben. Andernfalls wird ein Statuscode "Accepted" zurückgegeben, und der Client muss die Ressource abfragen, bis die endgültige Darstellung verfügbar ist.

Der Grund für dieses Verhalten ist folgender: Wenn innerhalb weniger Sekunden ein Ergebnis verfügbar ist, muss es so schnell wie möglich abgerufen werden. Andernfalls ist es nicht wichtig, wann es verfügbar wird.

Aufgrund des begrenzten Speichers und der schiere Menge an Anfragen ist weder NIO noch Long Polling eine Option (ie Ich kann nicht annähernd genug Verbindungen offen halten oder kann sogar alle Anfragen in den Speicher einpassen. ein paar Sekunden "sind vergangen, ich beharrte auf die überzähligen Anfragen). Ebenso sind Clienteinschränkungen so, dass sie stattdessen keinen Abschlussrückruf verarbeiten können. Beachten Sie schließlich, dass ich nicht daran interessiert bin, eine "Factory" -Ressource zu erstellen, zu der ein POST führt, da die zusätzlichen Roundtrips bedeuten, dass wir die stückweise Echtzeit-Einschränkung nicht mehr erfüllen, als erwünscht ist (außerdem ist dies zusätzliche Komplexität; dies ist auch eine Ressource, die dies tun würde) von Caching profitieren).

Ich kann mir vorstellen, dass es einige Kontroversen darüber gibt, dass als Antwort auf eine GET-Anforderung ein Statuscode "Accepted" zurückgegeben wird, da ich ihn noch nie in der Praxis gesehen habe. Seine intuitivste Verwendung ist die Antwort auf unsichere Methoden, aber ich habe es noch nie etwas gefunden, was es ausdrücklich entmutigt. Erhalte ich außerdem nicht gleichzeitig Sicherheit und Idempotenz?

Also, was denken die Leute über diesen Ansatz?

EDIT: Ich sollte erwähnen, dass dies für eine sogenannte Business-Web-API gilt - nicht für Browser.

74
user359996

Wenn es sich um eine gut definierte und -dokumentierte API handelt, klingt 202genau genau das, was passiert. 

Wenn es um das öffentliche Internet geht, wäre ich zu besorgt um die Kompatibilität der Kunden. Ich habe so viele if (status == 200) hartcodiert gesehen ... In diesem Fall würde ich einen 200 zurückgeben.

Auch macht das RFC keinen Hinweis darauf, dass die Verwendung von 202 für eine GET-Anforderung falsch ist, während es bei anderen Codebeschreibungen (z. B. 200) klare Unterschiede macht. 

Die Anforderung wurde zur Verarbeitung angenommen, aber die Verarbeitung wurde noch nicht abgeschlossen.

56
Pekka 웃

Wir haben dies für eine aktuelle Anwendung getan, ein Client (eine benutzerdefinierte Anwendung, kein Browser) hat eine Abfrage POST 'gestellt und der Server würde 202 mit einem URI an den "Job" zurücksenden, der gepostet wird Ergebnis - das scheint gut zu passen, was gemacht wurde.

Das Wichtigste ist hier trotzdem zu dokumentieren, wie Ihr Service/API funktioniert und was eine Antwort von 202 bedeutet.

10
nos

Soweit ich mich erinnern kann, soll GET eine Ressource zurückgeben, ohne den Server zu verändern. Vielleicht werden Aktivitäten protokolliert oder was haben Sie, aber die Anforderung sollte mit dem gleichen Ergebnis erneut ausgeführt werden können.

Auf der anderen Seite ist POST eine Anforderung, den Status von etwas auf dem Server zu ändern. Fügen Sie einen Datensatz ein, löschen Sie einen Datensatz, führen Sie einen Job aus. 202 wäre geeignet für ein POST, das zurückgegeben wurde, aber noch nicht abgeschlossen ist, aber nicht wirklich eine GET-Anforderung.

Es ist alles sehr puritanisch und in der Wildnis nicht gut geübt, so dass Sie wahrscheinlich sicher sind, indem Sie 202 zurückgeben. GET sollte 200 zurückgeben. POST kann 200 zurückgeben, wenn es fertig ist, oder 202, wenn es nicht fertig ist.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

9
Dlongnecker

Wenn eine Ressource eine Repräsentation einer Entität haben soll, die eindeutig durch eine ID angegeben ist (im Gegensatz zu einer "Factory" -Ressource, wie in der Frage beschrieben), empfehle ich, bei der GET-Methode zu bleiben und in einer Wenn die Entität/Repräsentation aufgrund einer verzögerten Erstellung oder einer anderen vorübergehenden Situation nicht verfügbar ist, verwenden Sie den Antwortcode 503 Service Unavailable (Nicht verfügbarer Service nicht verfügbar), der besser geeignet ist und eigentlich für Situationen wie diese entwickelt wurde.

Gründe hierfür finden Sie in den RFCs für HTTP selbst (bitte überprüfen Sie die Beschreibung des 503-Antwortcodes) sowie in zahlreichen anderen Ressourcen.

Bitte vergleichen Sie mit HTTP-Statuscode für vorübergehend nicht verfügbare Seiten . Obwohl es sich bei dieser Frage um einen anderen Anwendungsfall handelt, bezieht sie sich tatsächlich auf genau dieselbe Funktion von HTTP.

0
Hermes