If I do a Technorati search for some URL (say, this blog), I get the Technorati search page. In the upper right I notice an image "Add to watch list". That's right, if I click the link, the browser will do an HTTP GET on URL http://technorati.com/watchlist/add/hughw.blogspot.com, and change my watch list. I guess it must be a good thing that the above URL modifies your watchlist, not mine, if you click it. Although a lot of people would call it a bad thing for your identity cookie to make an URL identify one resource for me, another resource for you. I guess if you're going to introduce side effects for GET, you might as well fix it by making the URI identify multiple resources.
Update: I could be off base with the side effects argument. The side effect of clicking the link N times really is the same as clicking it once, which is all RFC 2616 asks. Something in me reacted to having clicking a link change some state, but I guess I shouldn't get my panties in a bunch about it. Still, the URL identifies your watch list for you, and my watch list for me. That's wrong, isn't it?
Hugh Winkler holding forth on computing and the Web
Subscribe to:
Post Comments (Atom)
3 comments:
You were right to begin with; it's bad for GET to have a state-changing result like the one you describe (i.e. one whereby the responsibility of the change falls on you). See section 9.1.1 of RFC 2616 instead of 9.1.2.
You've described idempotency, actually. HTTP does require that GET is safe as well. Specifically, that the user is intending and aware that the effects will occur when the GET is done. Watchlist modification is not in that camp.
WRT to the RESTfulness of the URI, it's up to the server to define the authority of the URIs they generate... so who can complain? :)
--
...jsled
http://asynchronous.org/jsled
Got it, guys. I knew in my bones it was wrong. Just can't read a spec.
Post a Comment