Responce code for failure in a syncronous POST request

[Andriy Yurchuk]

I send a POST request to the server. The request itself is syntactically correct and the REST server itself would have responded with a 200 OK. However there is some further processing occurring behind the REST server. Let's say it's a directory copy. The question is which HTTP status code should I return if the copy operation fails (not enough space, disk failure etc.)? The only idea I've come up with is 500, but this is not a good idea to respond with a 500 status code as far as I know.

[mca]

If the problem is "fixable" by the client (e.g. alter body and resubmit) then send a 400.

If the problem is not something the client can fix (e.g. insufficient disk space, etc. send 500.

Either way, be sure to send a message body w/ the status to report app-specific details (e.g. "you don't have enough space in your account" or "remove line feeds and submit again", etc.) so that client apps will be able to reflect that information to users (or write it in a log for bot--driven apps).

mca

+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Tue, Mar 5, 2013 at 11:35 PM, Andriy Yurchuk <ayur...@gmail.com> wrote:

I send a POST request to the server. The request itself is syntactically correct and the REST server itself would have responded with a 200 OK. However there is some further processing occurring behind the REST server. Let's say it's a directory copy. The question is which HTTP status code should I return if the copy operation fails (not enough space, disk failure etc.)? The only idea I've come up with is 500, but this is not a good idea to respond with a 500 status code as far as I know.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Steve Klabnik]

As usual, the answer is generally 'create more resources.' The POST should return a 201 with the location of a resource the represents the process, it can then return success or failure as needed. This info is probably in the response and not in the status code, though.

On Mar 5, 2013, at 8:35 PM, Andriy Yurchuk <ayur...@gmail.com> wrote:

I send a POST request to the server. The request itself is syntactically correct and the REST server itself would have responded with a 200 OK. However there is some further processing occurring behind the REST server. Let's say it's a directory copy. The question is which HTTP status code should I return if the copy operation fails (not enough space, disk failure etc.)? The only idea I've come up with is 500, but this is not a good idea to respond with a 500 status code as far as I know.

--

[Andriy Yurchuk]

Thanks Steve, but your solution would be suitable for an asynchronous API. In my case I need to wait for all the operations behind the POST request to be finished (successfully or not).

[Andriy Yurchuk]

Mike, I thought showing a 500 to the client is generally not considered a good practice, is it?

[Carlos Eberhardt]

I've heard that before. I think it comes from website thinking rather than web api thinking. The anti-pattern to avoid is misusing the defined response codes.

Carlos

[Bram Klein Gunnewiek]

If an internal server error occurs that can not be fixed (e.g. an Exception) and you can send a response back, the 500 status code is the only reasonable code you can use in your response. Since the request is synchronous, this sending back a 500 code back should be perfectly fine. You can't send 2XX since it failed, you can't send 4xx since the client did everything right, you can't send 3xx since there is no redirect ... you can only send 5xx since something went wrong on your side and the request simply can't be processed (now).

[sune jakobsson]

We also use 500 if there is some back-end internal issues, but add
some message to explain the exception