whenToUseGet-7 (ISSUE-7)

...looking at <http://www.w3.org/2001/tag/2008/01/17-minutes#item04>:

> HT: The section on in the draft HTTP 1.1 RFC update on safe and idemptotent operations seems at odds with with what we're talking about. See: http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-03.html#rfc.section.9.1

Note that the text you're looking at is the same in RFC2616.

> ... Let's say I'm going to put a CGI script at the URI of the w3c home page, and only changes member of the day every 1000 gets. That seems fine to me. It sure seems to violate 9.1.2 in the draft RFC, because the requests certainly aren't idempotent.
> 
> TBL: But the user hasn't bought into that contract.
> 
> HT: Yes, I agree, that's what I think too, but section 9.1.2 doesn't account for that being OK. When I read 9.1.2, incrementing a counter seems a side affect in my book. 

As TBL said, the user didn't request the change.

There's a related open issue 
(<http://tools.ietf.org/wg/httpbis/trac/ticket/27>), "PUT Idempotency", 
which in fact effects (IMHO) the definition of idempotency in general. 
See in particular Roy's comment in 
<http://tech.groups.yahoo.com/group/rest-discuss/message/7387>:

"Just ignore the definition of idempotent in RFC 2616. Anything
specified in HTTP that defines how the server shall implement the
semantics of an interface method is wrong, by definition. What
matters is the effect on the interface as expected by the client,
not what actually happens on the server to implement that effect."

Later...:

> <DanC> (indeed, the visible counters run counter to the HTTP spec. they're an abuse.)
> 
> <ht> OK DanC, we're in agreement -- _should_ they be ruled out by the HTTP spec. 

Dan, could you please clarify what exactly you think should be changed 
in the HTTP spec? As far as I can tell, counter-like resources are 
clearly allowed.

BR, Julian

Received on Saturday, 19 January 2008 12:00:22 UTC