0

It has been said that "PUT is idempotent":

The difference between PUT and POST is that PUT is idempotent: calling it once or several times successively has the same effect (that is no side effect), whereas successive identical POST requests may have additional effects, akin to placing an order several times.

How do I correctly interpret that? That PUT must be idempotent?

If a PUT method is returning a different output for the same input that should mean it is not correctly implemented and therefore it is a bug?

1
3

Reminder: the real definitions for HTTP methods are those published in the specifications that are registered with IANA.

In the case of PUT, the real definitions are in RFC 7231.

How do I correctly interpret that? That PUT must be idempotent?

The semantics are idempotent.

An important element of the REST architectural style is the uniform interface constraint; roughly: everybody understands all requests and responses the same way.

That means that we can stick a general purpose cache in front of a web server, and everything "just works" -- we all use messages the same way, so the cache can do intelligent things with requests. Everybody understands messages the same way, so we get inter-op "for free".

Because GET and PUT requests have idempotent semantics, duplicate copies of the same request mean the same thing. One useful consequence of that is we can automatically retry those requests if the response is lost - a very useful property when the message transport is unreliable.

But it doesn't mean that the request handler MUST handle the request in an idempotent way. What it means is that the implementation is responsible for any loss of property caused by the fact that the implementation doesn't respect the semantics of the request. See Fielding 2002.

If a PUT method is returning a different output for the same input that should mean it is not correctly implemented and therefore it is a bug?

Not necessarily: idempotent constrains the semantics of the request, not the mapping of which response goes with which request.

3
  • 1
    Agreed. A reasonable response to a PUT could include things such as the time the change was made and a UUID for the change event. Those would not be expected to ever be the same. Idempotency is abut what happened to the state of the resource. – JimmyJames Jun 16 at 17:13
  • 1
    "What it means is that the implementation is responsible for any loss of property caused by the fact that the implementation doesn't respect the semantics of the request." - but that's just another way of saying that such an implementation is faulty (doesn't adhere to the semantics of the interface), and that those responsible for the implementation can be held liable for any resulting damage (as opposed to blaming it on the user who issued the request, or the design/semantics of the API). It's just that the standard has no way of enforcing the implementation to this level. – Filip Milovanović Jun 16 at 19:50
  • That's like saying, a virtual method named readData() doesn't mean that an implementation MUST only do a read, it only requires that the semantics of the operation (say, an abstract description of what the method does) conform to this read-only idea, and therefore it is a fault of the implementation, not the interface or the user of that interface, if an implementation deletes the database. I mean, what can I say, it's technically correct (the best kind of correct). – Filip Milovanović Jun 16 at 19:57
1

I think it is not a "must", but a convention. Technically I could do DELETE /users in my app to fetch the list of users in my database. Is that bad? Not really if it is just for my use, because this will effect noone else other than me (and I mean me, as a dev amusing myself, living life on the edge, alone, not as a part of a team or working on a codebase that has any intention of becoming serious).

It does not automatically mean that it is a bug, but if you send the same request again, you should receive the same response.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.