Timeline for HTTP Status Code for "Still Processing"
Current License: CC BY-SA 3.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 20, 2022 at 17:27 | comment | added | Lee |
In the case of an asynchronous process like video conversion or the notorious long-running report it seems that the API server is acting as a proxy for the result, which would make a response to the GET for the result of 203 Non-Authoritative Information perhaps viable when the result is still partial/in-process? I read the definition of "subset or superset" as perhaps including the trivial subset of "nothing yet" (i.e. information from the api service rather than the video conversion service, which seems to be "another source").
|
|
| Oct 7, 2021 at 7:34 | history | edited | CommunityBot |
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
|
|
| Jun 24, 2021 at 13:56 | comment | added | Géry Ogam |
Are you sure? Argument 1 does not seem to apply because in the JSON body of your response to a GET request to /video/status/123 you could have an extra key "result" with the value null until the result resource is ready, and with the value "/video/status/123" after, so the JSON structure would not change. Argument 2 does not seem to apply because you still get the status (and a link to the video) when the video is available, not the video. Argument 3 does not seem to apply because /video/status/123 always identifies the status (and a link to the video when available).
|
|
| Jun 24, 2021 at 13:48 | comment | added | Arseni Mourzenko | @Maggyero: the same arguments apply. | |
| Jun 24, 2021 at 13:03 | comment | added | Géry Ogam |
Thanks, these are very compelling arguments. And instead of a 303 redirection response with the product URI (/video/status/123) in the Location header field when the product resource is available, what do you think of a 200 success response with the product URI in the body when the product resource is available?
|
|
| Jun 24, 2021 at 6:29 | comment | added | Arseni Mourzenko |
@Maggyero: I think it is a bad idea for three reasons. (1) A resource which completely changes its type depending on some internal state of the system is counter-intuitive. (2) As a caller, when I ask for status, I may want to get back status, not the whole video; I might have a very different processing for videos themselves; maybe even I check for status from one machine/container, and grab the video itself from another one. (3) A video identified by /video/status/123 URI doesn't make sense whatsoever.
|
|
| Jun 24, 2021 at 0:32 | comment | added | Géry Ogam |
Instead of still responding with 200, what do you think of redirecting the client to the processing result with 303 after the request has been completed, like suggested in the article REST and long-running jobs?
|
|
| Dec 31, 2020 at 2:37 | comment | added | balrob | @ArseniMourzenko Thanks for this response, and it got me thinking. As our own web server provides server-sent-event streams it occurred to me that the original POST could be responded to with a "text/event-stream" stream, providing regular status messages culminating in the url to download the finished content. | |
| Jun 11, 2020 at 5:42 | vote | accept | Matthew Haugen | ||
| Apr 30, 2020 at 10:38 | comment | added | David Cowden |
@ArseniMourzenko semantically, I think a more natural REST design is: POST /videos, and GET /videos/:id. status would be a field on the video's record. The resource would also have url field where a client could query to get the actual video (which might be /download/:id, but also might be /videos/:id/raw perhaps with a content header or query param to select the desired format).
|
|
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot |
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
|
|
| Apr 20, 2016 at 16:55 | comment | added | Brian | @MatthewHaugen: OK, it's an answer. | |
| Apr 20, 2016 at 16:15 | comment | added | Matthew Haugen | @Brian Your comment would make a reasonable answer to this question. Although I would then respond with "[t]his code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request," which isn't strictly true in my case, but that seems less wrong than "not found." A part of me is leaning toward a 409 with a Retry-After header pinned on. The only issue is that it seems weird to return a 409 for a GET, but I can live with that weirdness--it's unlikely to be otherwise-defined in the future. | |
| Apr 20, 2016 at 13:26 | history | edited | Arseni Mourzenko | CC BY-SA 3.0 |
added 179 characters in body
|
| Apr 20, 2016 at 13:22 | comment | added | Brian | HTTP Status Code for Resource not yet available suggests returning a 409 conflict response ("The request could not be completed due to a conflict with the current state of the resource. "), rather than a 404 response, in the case that a resource doesn't exist because it is in the middle of being generated. | |
| Apr 20, 2016 at 13:21 | history | edited | Arseni Mourzenko | CC BY-SA 3.0 |
deleted 1 character in body
|
| Apr 19, 2016 at 19:32 | history | edited | Arseni Mourzenko | CC BY-SA 3.0 |
added 1916 characters in body
|
| Apr 19, 2016 at 19:26 | history | edited | Arseni Mourzenko | CC BY-SA 3.0 |
added 1916 characters in body
|
| Apr 19, 2016 at 19:11 | comment | added | Arseni Mourzenko |
@MatthewHaugen: when you do the GET part, don't think about it as a incomplete request, but as a request to get the result of the operation. For instance, if I tell you to convert a video and it takes you five minutes to do it, requesting for a converted video two minutes later should result in HTTP 404, because the video is simply not there yet. Requesting for the progress of the operation itself, on the other hand, will probably result in an HTTP 200 containing the number of bytes converted, the speed, etc.
|
|
| Apr 19, 2016 at 19:06 | comment | added | Matthew Haugen |
@MainMa Like I said, I POST up the job to be queued, then I GET the results, potentially after the client has closed the session. A 404 is something I've considered as well, but it seems wrong, since the request is found, it just hasn't been completed. That would indicate to me that the queued job was not found, which is a very different situation.
|
|
| Apr 19, 2016 at 18:40 | comment | added | Arseni Mourzenko |
@MatthewHaugen: I don't think GET is a good idea anyway in this context. You said that the request “queu[es] long-running tasks”, which should be done through POST (otherwise, you'll end up queuing the same item multiple times, or not queuing it at all). As for telling the client that the response isn't ready yet during polling, a simple HTTP 404 would work.
|
|
| Apr 19, 2016 at 18:36 | history | edited | Arseni Mourzenko | CC BY-SA 3.0 |
added 160 characters in body
|
| Apr 19, 2016 at 18:22 | comment | added | Matthew Haugen | I totally agree with your last paragraph, but that's my question: "either let the user to get back to you later to determine whether the processing ended," how should I tell the client that it hasn't? | |
| Apr 19, 2016 at 18:21 | comment | added | Matthew Haugen |
Does a 202 make sense in response to a GET, though? That's certainly the correct choice for the initial POST, which is why I'm using it. But it seems semantically suspicious for a GET to say "accepted" when it didn't accept anything from that particular request.
|
|
| Apr 19, 2016 at 18:19 | comment | added | Eric Stein | RFC 2616 is out of date. See 7230 - 7235. | |
| Apr 19, 2016 at 18:16 | history | edited | Arseni Mourzenko | CC BY-SA 3.0 |
added 731 characters in body
|
| Apr 19, 2016 at 18:07 | history | answered | Arseni Mourzenko | CC BY-SA 3.0 |