HTTP status code for “success with errors”?

Question

I\'ve poked around a bit, but I don\'t see an HTTP status code for when a request\'s succeeds, but there is an error after the \"point of no return\".

e.g., Say you

Answer 1

I agree with @Daniel that the proper response is an HTTP 500 (server error). The web application has to be written to roll back the transaction when there is an error, not leave things half-finished.

One thing you can leverage in your web application is "idempotency". This is the property of a function (or operation) that you can repeat it as many times as you like with the same result. For instance if a read fails, the client can simply retry it until it succeeds. If a deletion appears to fail, the client can again retry and the server will treat the request as valid whether or not the resource being deleted is already gone. And if an update appears to fail, the client can retry that until it gets a successful return from the server. The REST approach to architecting web services makes heavy use of idempotency to make operations robust in the face of error.

Answer 2

HTTP doesn't have such a status code, but there is a best practice that allows you to handle such situations - redirect the user after a POST operation.

Here is a break down -

1. A POST request tries to modify data on the server
2. If the server fails, it sends a 500 error to indicate failure
3. If the server succeeds, it sends a 302 redirect response
4. The browser then sends a fresh GET request to the server
5. If this fails, you get a 500 error, otherwise you get a 200

So, your use case of 'Saved data but can't retrieve it immediately' translates to a 302 redirect for the initial POST, followed by a 500 for the subsequent GET.

This approach has other advantages - you get rid of the annoying 'Are you sure you want to resubmit the data?' message. Also keeps your back/forward/refresh buttons usable.

Answer 3

If the server is aware that it has encountered a problem, it should normally return a 5xx error. The most generic one is the 500 Server Error, which the RFC 2616 defines as follows:

500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

Then it's the client's responsibility to reattempt the request. If the previous request was partially committed, it's the server's (or the database's) responsibility to roll that back, or to handle the duplicate transaction appropriately.