HTTP 202 akzeptiert (HTTP / 1.1)
Sie suchen nach HTTP 202 AcceptedStatus. Siehe RFC 2616 :
Die Anforderung wurde zur Verarbeitung angenommen, die Verarbeitung wurde jedoch nicht abgeschlossen.
HTTP 102-Verarbeitung (WebDAV)
RFC 2518 schlägt vor, Folgendes zu verwenden HTTP 102 Processing:
Der Statuscode 102 (Verarbeitung) ist eine Zwischenantwort, mit der dem Client mitgeteilt wird, dass der Server die vollständige Anforderung akzeptiert, jedoch noch nicht abgeschlossen hat.
aber es hat eine Einschränkung:
Der Server MUSS eine endgültige Antwort senden, nachdem die Anforderung abgeschlossen wurde.
Ich bin mir nicht sicher, wie ich den letzten Satz interpretieren soll. Sollte der Server während der Verarbeitung das Senden von Daten vermeiden und erst nach Abschluss der Verarbeitung antworten ? Oder erzwingt es nur, die Antwort zu beenden, wenn die Verarbeitung beendet wird? Dies kann hilfreich sein, wenn Sie den Fortschritt melden möchten. Senden Sie HTTP 102 und leeren Sie die Antwort Byte für Byte (oder Zeile für Zeile).
Für einen langen, aber linearen Prozess können Sie beispielsweise einhundert Punkte senden, die nach jedem Zeichen rot werden. Wenn die Clientseite (z. B. eine JavaScript-Anwendung) weiß, dass sie genau 100 Zeichen erwarten sollte, kann sie diese mit einem Fortschrittsbalken abgleichen, der dem Benutzer angezeigt wird.
Ein weiteres Beispiel betrifft einen Prozess, der aus mehreren nichtlinearen Schritten besteht. Nach jedem Schritt können Sie eine Protokollmeldung löschen, die dem Benutzer möglicherweise angezeigt wird, damit der Endbenutzer weiß, wie der Prozess abläuft.
Probleme mit fortschreitender Spülung
Beachten Sie, dass diese Technik zwar ihre Vorzüge hat, ich sie jedoch nicht empfehlen würde . Einer der Gründe dafür ist, dass die Verbindung offen bleiben muss, was sich negativ auf die Verfügbarkeit des Dienstes auswirken kann und sich nicht gut skalieren lässt.
Ein besserer Ansatz ist es, mit zu antworten HTTP 202 Acceptedund entweder den Benutzer später auf Sie zurückkommen zu lassen, um festzustellen, ob die Verarbeitung beendet wurde (z. B. durch wiederholtes Aufrufen einer bestimmten URI, /process/resultdie bis zum Abschluss des Prozesses mit HTTP 404 Not Found oder HTTP 409 Conflict antworten würde ) beendet und das Ergebnis ist fertig), oder benachrichtigen Sie den Benutzer, wenn die Verarbeitung abgeschlossen ist, wenn Sie den Client beispielsweise über einen Message Queue-Service ( Beispiel ) oder über WebSockets zurückrufen können.
Praktisches Beispiel
Stellen Sie sich einen Webdienst vor, der Videos konvertiert. Der Einstiegspunkt ist:
POST /video/convert
Das nimmt eine Videodatei von der HTTP-Anfrage und macht etwas Magie damit. Stellen wir uns vor, die Magie ist CPU-intensiv und kann daher während der Übertragung der Anforderung nicht in Echtzeit ausgeführt werden. Dies bedeutet, dass der Server nach dem Übertragen der Datei mit einem HTTP 202 AcceptedJSON-Inhalt antwortet. Dies bedeutet: „Ja, ich habe Ihr Video und arbeite daran. es wird irgendwann in der Zukunft fertig sein und unter der ID 123 erhältlich sein. “
Der Client hat die Möglichkeit, eine Nachrichtenwarteschlange zu abonnieren, um benachrichtigt zu werden, wenn die Verarbeitung abgeschlossen ist. Sobald es fertig ist, kann der Client das verarbeitete Video herunterladen. Gehen Sie dazu zu:
GET /video/download/123
was zu einer HTTP 200.
Was passiert, wenn der Client diesen URI abfragt, bevor er die Benachrichtigung erhält? Nun, der Server antwortet mit, HTTP 404da das Video noch nicht existiert. Es kann derzeit vorbereitet werden. Möglicherweise wurde es nie angefordert. Es kann einige Zeit in der Vergangenheit existieren und später entfernt werden. Wichtig ist nur, dass das resultierende Video nicht verfügbar ist.
Was ist nun, wenn sich der Kunde nicht nur um das endgültige Video, sondern auch um den Fortschritt kümmert (was noch wichtiger wäre, wenn es keinen Message Queue Service oder einen ähnlichen Mechanismus gibt)?
In diesem Fall können Sie einen anderen Endpunkt verwenden:
GET /video/status/123
was zu einer ähnlichen Antwort führen würde:
HTTP 200
{
"id": 123,
"status": "queued",
"priority": 2,
"progress-percent": 0,
"submitted-utc-time": "2016-04-19T13:59:22"
}
Wenn Sie die Anforderung immer wieder ausführen, wird der Fortschritt angezeigt, bis Folgendes zutrifft:
HTTP 200
{
"id": 123,
"status": "done",
"progress-percent": 100,
"submitted-utc-time": "2016-04-19T13:59:22"
}
Es ist wichtig, einen Unterschied zwischen diesen drei Arten von Anfragen zu machen:
POST /video/convertStellt eine Aufgabe in die Warteschlange. Es sollte nur einmal aufgerufen werden: Ein erneuter Aufruf würde eine zusätzliche Aufgabe in die Warteschlange stellen.GET /video/download/123betrifft das Ergebnis der Operation: Die Ressource ist das Video. Die Verarbeitung - das ist, was unter der Haube passiert ist, um das tatsächliche Ergebnis vor der Anforderung und unabhängig von der Anforderung vorzubereiten - ist hier irrelevant. Es kann ein- oder mehrmals aufgerufen werden.GET /video/status/123betrifft die Verarbeitung an sich . Es steht nichts in der Warteschlange. Das resultierende Video ist ihm egal. Die Ressource ist die Verarbeitung selbst. Es kann ein- oder mehrmals aufgerufen werden.