Using HTTP 304 in response to POST

Question

I have a REST API that allows modification of resources using HTTP POST. It's possible that a client may submit a POST request that results in no modification of the resource. I'm thinking about using the 304 response generally used for conditional responses to indicate that the request had no effect. I haven't been able to find any examples of this being done, so I figured I'd ask here and see if anyone else is doing this or has an opinion about it.

Fluky

In many cases, the most appropriate response code for a POST request which failed to modify or create a resource should be 409 (Conflict). You should clarify what you are trying to accomplish. – Girvin

If, for whatever reason, the client submits a POST with the exact same state that the resource already has, there will be no side effect to the request - i.e. the resource will not be modified - so 304 seems like an appropriate response. It's certainly not an error in my API, so 409 is not appropriate. Normally, of course, the client will ask for a change and the response will be 200 with the new state of the resource. – Fluky

In this case, IMHO a PUT (or a PATCH) request is more appropriate. Then, the RFC is quit clear about this scenario: if the request-URI of a PUT request refers to an existing resource, the resource should be considered modified and the server responds with 200 (OK) or (204 No Content). The server might send a response with more detailed info. That is, even if the resources ends up unmodified, it is considered modified. IMO, this makes sense. – Girvin

PUT is only appropriate where the request includes the entire state of the resource which is never the case in my API since the state of the resource depends on other resources and a client may choose to mutate some part of the resource without caring about the other parts. Even so, the RFC is rather vague about what a 200 or 204 response means. Is 204 intended to signify that no change occurred? PATCH makes sense, but I feel it is not yet 'standard' enough to consider and the response code situation is still vague. – Fluky

Answer 1

After some consideration, I've decided to stick to a normal 200 response with the unchanged resource entity. My initial intent was to provide a concise way to indicate to the client that the resource was not modified. As I thought more about it I realized that in order to do anything useful with the 304 response, they would have to already have a cached version and in that case it would be trivial to compare the version of the cached copy with the version returned in a 200 response.

Fluky

Sure. 304 is about the unmodified response, not really about the resource. You can use 304 only if the response has been cached and the client issued a conditional request. The client isn't obliged to cache anything, so you can't rely on sending 304. Moreover, your Javascript gets 200 instead of 304 (probably for security reasons). – Songer

Answer 2

I have a REST API that allows modification of resources using HTTP POST. It's possible that a client may submit a POST request that results in no modification of the resource.

HTTP POST in the RESTful approach implies a creation of a resource, not a modification. For modification you should use HTTP PUT.

Solution of your problem is HTTP Status 200 OK when something was modified and HTTP Status 204 No Content when there was no modification. According to:

The common use case is to return 204 as a result of a PUT request, updating a resource, without changing the current content of the page displayed to the user. If the resource is created, 201 Created is returned instead. If the page should be changed to the newly updated page, the 200 should be used instead.

-- MDN web docs

---

For example:

-- Request
POST /people HTTP/1.1
Content-Type: application/json

{
    "name": "John"
}

-- Response
HTTP/1.1 201 Created
Location: /people/1

-- Request
PUT /people/1 HTTP/1.1
Content-Type: application/json

{
    "name": "John"
}

-- Response
HTTP/1.1 204 No Content

-- Request
PUT /people/1 HTTP/1.1
Content-Type: application/json

{
    "name": "Robert"
}

-- Response
HTTP/1.1 200 OK
Content-Type: application/json

{
    "name": "Robert"
}

Gert

"HTTP POST in the RESTful approach implies a creation of a resource, not a modification. For modification you should use HTTP PUT." I disagree with this. PUT should be used for complete replacement of the resource with a new one. POST can be used to make changes to a resource. E.g. from Spring's "Understanding REST" page : "Request that the resource at the URI do something with the provided entity. Often POST is used to create a new entity, but it can also be used to update an entity." – Greece

Technically, for changing a resource the correct method is PATCH. PUT really should be used for replacing the resource, rather than changing the resource. – Matutinal