Timeline for HTTP Status Code for "Still Processing"
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 18, 2022 at 13:46 | comment | added | Géry Ogam | @AnorZaken In hindsight, I think Cormac is right. I conflated the duration with the start of request processing. When the processing outlives the connection (long process), the server should immediately send a response describing the duration of the processing (with the 201 status code and Location header field if it creates a subordinate resource representing the process for monitoring, with 200 otherwise). When the processing of a request is delayed (asynchronous process), the server should immediately send a response describing the start of the processing (with the 202 status code). | |
| Jan 18, 2022 at 8:42 | comment | added | AnorZaken | From the perspective of agnostic web-software, the software receives the 201, with a location, and can proceed to that location, where it can retrieve a resource. The web-software doesn't care that the resource happens to contain some json describing the status of some other resource it knows nothing about - a piece of json data that only our business logic understands. To drive the point home: HTTP-statuses exists so that the web-software can properly operate the communication between client and server - it does NOT exists to convey any business meaning to whatever runs on top of the web. | |
| Jan 18, 2022 at 8:37 | comment | added | AnorZaken | @Maggyero Have to agree with CormacMulhall here. The spec that is quoted in "Asynchronous processing (done wrong)" directly contradicts what he suggests doing in the "done right" part. Specifically the quoted spec says that whatever is put in the Location header is the primary reasource, then in the article he goes on to put the status-uri as the Location. This makes the status object the primary resource (and effectively relegates the result of our processing as a secondary resource). Thus the 201-status is the correct response, as the status resource is in Location and created immediately. | |
| Jun 25, 2021 at 10:58 | comment | added | Cormac Mulhall | Again the business logic concept of 'pending' is nothing to do with the state transfer of the HTTP request. The request to create the resource is not 'pending'. For example if I open a mortgage application that application could be in the "pending" state for 6 months, but the actual HTTP request returns immediately. REST doesn't care about the states the resource can be in (including any business logic related 'pending' state) it cares only about the state transfer. | |
| Jun 23, 2021 at 23:55 | comment | added | Géry Ogam | Sorry but what you are describing here is Asynchronous processing (done wrong). Using the status code 201 instead of 202 for long request processing is wrong. 201 means that the request has been completely processed (and resulted in the creation of one or more new resources), which is not the case here. ‘It is just the state of the resource is "Pending" (or something).’ No, this is not the state of the resource which is pending, this is the state of the request. The resource is the product of this processing. | |
| Apr 24, 2016 at 0:06 | comment | added | Cormac Mulhall | The resource is created, it is just in the state "pending". That is in itself relevant data. At some point in the future the server may change the resources state to "completed" (or "failed") but that is a different concept to the HTTP domain specific task of "create the resource". Pending can be a perfectly valid state for a "Request" resource to be, and the client obviously wants to know the server has created the resource in that state since it moves from asking the server to create the resource to know polling it to find out if the state changed. | |
| Apr 22, 2016 at 23:01 | comment | added | Andy | No one cares if the url exists but you can't get the data the resource represents because it's still being processed. Might as well NOT create the url until it can be used to get the video. | |
| Apr 22, 2016 at 9:13 | comment | added | Cormac Mulhall | The thing is the server is acting immediately. It creates the resource with a URL immediately. It is just the state of the resource is "Pending" (or something). That is a business domain state. As far as the HTTP Protocol is concerned the server acted as soon as it created the resource and gave the client the URL of the resource. You can GET that resource. The POST request itself is not pending. This is what I mean by keeping the two different conceptual domains separate. If the client was sending a fire and forget POST request not acted upon for hours then 202 would be applicable. | |
| Apr 21, 2016 at 22:24 | comment | added | Andy | "Did the POST from the client to the server transfer a resource to the server, where the server then gave it a URL that the client can view? Yes? Then that is a 201 Created response." 202 Accepted is also acceptable as a response to this if the server cannot act immediately to process the resource, which is what the OP is doing. | |
| Apr 21, 2016 at 15:48 | history | answered | Cormac Mulhall | CC BY-SA 3.0 |