Token server design - RFC

Toby Elliott telliott at
Thu Jan 12 20:06:33 PST 2012

On Jan 12, 2012, at 5:44 PM, Gregory Szorc wrote:

> On 1/12/12 5:38 PM, Toby Elliott wrote:
>> On Jan 12, 2012, at 5:29 PM, Ryan Kelly wrote:
>>> However, this doesn't really "feel" like a GET request to me.  You're
>>> (conceptually) creating new server-side state by starting a new session,
>>> and the response will be different for each request, is not cacheable,
>>> etc.  It feels like it should still be a POST request.
>>> That's a pretty small nit though :-)
>> Ha! I argued the other way - you're requesting the value of a resource, not modifying that resource based on data you submit. I agree that it's not an awesome fit either way :P
>> You're right that it's not idempotent, but the response is actually cacheable.
> The response is not idempotent, therefore it fails to satisfy the requirements in RFC 2616 Sec 9.1.2. POST it must be.

Man, now you have me digging in the spec. Of course, all this is totally irrelevant, but it's kind of interesting :)

My reading of 9.1.2 actually suggests that the request is idempotent. Setting aside one edge case (the user first gets a node), multiple requests to the resource do not result in any side effects. The response to the call changes each time you access it, but that's due to factors external to the request.

If this request isn't considered idempotent, then any request to a function that just returned the current timestamp would not be considered allowable as a GET call. That's the only reason the response changes.


More information about the Services-dev mailing list