I’m reading a Java standard right now and it contains a very common mistake:
Render URLs should not be used for tasks that are not idempotent, i.e. that change state… they should not change any state on the server. As a consequence, render URLs may become
That’s not what idempotent means. It’s just what a lot of people seem to think it means.
The RFC that describes HTTP gives a very precise definition of idempotent:
the side-effects of N > 0 identical requests is the same as for a single request
The exact implications of this may not be obvious, but what is surely obvious is that side-effects (changes of state) are not ruled out.
Thinking about a “delete” operation is extremely helpful here. Suppose the operation takes an integer parameter identifying an item in a list that should be deleted from that list. The question is, do we interpret that parameter as an ID or a position?
If it’s an ID, then the delete operation can easily be made idempotent. If the caller asks you to delete item number 3, and you can’t find any item with that ID, you just ignore the operation. That way, multiple requests to delete item number 3 will have the same effect as a single such request.
But if the parameter is interpreted as a position (index) within the list, then it won’t be idempotent, because when you delete item number 3, what was item 4 will move along to become the new item 3. So a second request to delete item number 3 will now delete that item.
So in the context of computing, there is a very strong association between idempotency and things having their own unique identity that doesn’t change, so you can refer to them by their identity unambiguously. (It’s therefore not surprising that it’s such an important concept when discussing anything that has a URL.)