CODEWITHSUNDEEP
resthttp
Tim Lovell-Smith
Tim Lovell-Smith

Reputation: 16125

Should HTTP server return 200 when PUT is a no-op?

I've reread the HTTP spec.

It states that PUT should be treated as a request to modify the existing resource if the resource has already been created.

It states that PUT should return either 200 or 204 when it succeeds, but did not create the resource.

It states that PUT should be idempotent and have no unwanted side effects when it is invoked multiple times with the same identical request.

What it does not seem to state is that -PUT should return success when it is an idempotent scenario with no side effects, and only success, (and not e.g. 409 conflict in response to a server detected no-op PUT request where the server wants to disallow no-ops).

My question is, what is the best thing to do? Either:

  1. did I miss anything? Either in HTTP spec, or other well-known REST guidelines, what didn't I see?

or

  1. assuming you know of nothing I missed, what is your opinion on whether 200 should be HTTP's recommended behavior? Why? Can you think of any good reason not to return 200/204 for a no-op?

Upvotes: 3

Views: 3007

Answers (1)

Pedro Werneck
Pedro Werneck

Reputation: 41918

Yes, you should return 200 or 204.

First of all, PUT is not treated as a request to modify the existing resource. You're probably reading RFC 2616, which is obsoleted by RFC 7231 on this. PUT is always a request to replace the resource at the given URI, but this wasn't very clear on RFC 2616. In case it already exists, the paylod SHOULD be a modified version of the same resource, but the operation still is a complete replacement, not a modification.

In that sense, there's no such thing as no-op PUT, you're always replacing what is identified by that URI, even if by the exact same thing. Whether changes occurred from the point of view of the client is irrelevant. For the server, what matters is that the whole thing was replaced.

As a general rule, the semantics of the GET, PUT, PATCH and DELETE methods should be easily generalized for everything, and if you're adding to their semantics something already available through something else, you're probably doing something wrong. To return an error on a no-op request because no changes would occur to the resource can be achieved with the precondition headers if that's what the client wants, so it doesn't make sense to make that part of the PUT semantics.

Upvotes: 4

Related Questions