If a GET request's response changes, is idempotency respected?

Question

I am reading a lot about rest API and I always stumble upon terms idempotency. Basically GET, HEAD, PUT, DELETE and OPTIONS are all idempotent, and POST is not.

This statement on http://www.restapitutorial.com/lessons/idempotency.html made me doubt my understanding of idempotency.

From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server (no side effects), the response itself may not be the same (e.g. a resource's state may change between requests).

So does idempotency actually has something to do with server-work or a response?

What confuses me if I have

GET /users/5

returning

{
"first_name" : "John",
"last_name" : "Doe",
"minutes_active": 10
}

and then do the same request after one minute I would get

GET /users/5
{
"first_name" : "John",
"last_name" : "Doe",
"minutes_active": 11
}

How is this idempotent?

Furthermore if response contains some kind of UUID which is unique for each response, would that break idempotency?

And finally, is idempotency same server-work over and over again, or same results over and over again for the same/single request?

Answer 1

So does idempotency actually has something to do with server-work or a response?

It refers to the server state after subsequent request of the same type.

So, lets suppose that the client makes a request that changes the server's old state, for example S1, to a new state, S2, then makes the same request again.

If the method is idempotent then it is guaranteed that the second request would not change the server's state again, it will remain S2.

But if the method is not idempotent, there is no guarantee that the state would remain the same, S2; it may change to whatever state the server wants for example S3 or S1. So, in this case the client should not send the command again if a communication error occurs because the outcome would not be the same as the first time it sent the command.

GET /users/5 How is this idempotent?

You may call this url using GET method as many time you want and the server would not change its internal state, i.e. last_name of the user; if it does not change it, then it remains the same so GET is idempotent.

Furthermore if response contains some kind of UUID which is unique for each response, would that break idempotency?

The response has nothing to do with the server's state after subsequent requests of the same type so the response could be unique after each request and the request would still be idempotent. For example, in the GET request from your question, the minutes_active would be greater each minute and this does not make GET not-idempotent.

Other example of idempotent method is DELETE. For example if you delete a user then it is gone/deleted. Because DELETE is idempotent, after a second atempt/request to delete the same user, the user would remain deleted so the state would not change. Of course, the second response could be a little different, something like "warning, user already deleted" but this has nothing to do with idempotency.