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)
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.