Bei der Untersuchung von RESTful-APIs für asynchrone Vorgänge habe ich das folgende Entwurfsmuster durchlaufen:
POST uri:longOperation gibt zurück:
GET uri:pendingOperation gibt zurück:
GET uri:operationResponse
Ich finde den letzten Schritt fraglich. Überlegen Sie, was passiert, wenn der asynchrone Vorgang mit einem Fehlercode abgeschlossen wird, der für HTTP GET nicht sinnvoll ist, z. B. HTTP 409 ("Conflict") .
HTTP 303 erforderlich, um auf die Antwort zu verweisen, die mit uri: pendingOperation im Gegensatz zu uri: operationResponse verknüpft ist? HTTP 303 auf diese Weise als schädlich? Wenn nicht, warum? Ist HTTP 303 nicht erforderlich, um auf die mit uri: pendingOperation verbundene Antwort im Gegensatz zu uri: operationResponse zu zeigen?
Die Spezifikation sagt nicht explizit, dass es erforderlich ist, aber ich tendieren dazu, dir zuzustimmen.
Wird HTTP 303 auf diese Weise als schädlich angesehen? Wenn nicht, warum?
Ich denke, Sie verlieren Fähigkeiten, indem Sie eine 303 ausführen. Obwohl es "schön" ist, automatisch umzuleiten, wenn Sie fertig sind, ist es so, dass Sie keine Gelegenheit haben, Metadaten rund um die Ergebnisse bereitzustellen, die genutzt werden können für die Berichterstellung usw. ... Auch folgen viele Clients nicht automatisch 303, so dass der Client möglicherweise Arbeiten ausführen muss, um dem 303-Standort-Header trotzdem zu folgen.
Ist das das Beste, was wir tun können, oder gibt es einen besseren Weg?
Ich empfehle tendenziell, dass GET uri:pendingOperation 200 mit einer Statusressource immer mit einem Verweis auf die Ausgabe zurückgibt, wenn sie "abgeschlossen" ist. Etwas wie
Wenn unvollständig
%Vor%Wenn Fehler
%Vor%Wenn erfolgreich
%Vor%Tags und Links rest http-status-code-303