REST: Correct HTTP Response Code For a POST Which Is Ignored

Question

We have a REST API which clients routinely POST and PUT data to. When they do this, sometimes they POST data which results in no change on our system. The POSTs and PUTs are well-formed, but they data they're sending is identical to the data in our database. When this happens, I've just found out that we're returning a 400 HTTP status. Unfortunatly, this means "bad request" as in "request could not be understood by the server due to malformed syntax".

Clearly this is not the case, but I'm told that we're going to use this since there's no other appropriate status code. Choices we've considered:

• 304 Not Modified. This, regrettably, is only for GET requests.
• 204 No Content. Seems close, but forbids an entity-body.

Other choices seem equally bad. We might go with 200 OK and have the relevant information in the XML document we return, but this doesn't seem very "RESTish". How does the REST world generally handle this?

(Fixed Not Modified response code. Thanks Mkoeller)

Answer 1

From client view the server status is the same if the request content was the same on the server or not, right? Since the server afterwards holds excactly the content that was sent, why should the server respond with any kind of error status? On the other hand why should the client bother if the request content was the same as already known to the server? It was successfully transfered to the server so the bulk of work is done. How is a client expected to react if there was a different response code for this situation?

Conclusion: Your situation of a request content equaling the existing content is no special case. You should respond with the same response status code. That might be 200, 302 or 303.

Answer 2

I think it's perfectly fine to return a 200 OK in that case, the data was correctly processed and the server did what it had to. Because the server processed correctly the data, it should return an OK status code. The fact that it ignored it internally is or should be irrelevant.

What the server did to the data should not be told to the clients, they should be told what happened to the request (processed ok, error occurred, and the like).

And if, for some weird reason (I can't think a valid one, btw), it is of interest to the clients, you have the response to tell them so.

Answer 3

If the clients are able to know the entity tag for the content on the server before they PUT, then using If-Match headers and the 412 Precondition Failed response exists for exactly the situation you describe.