Well.... maybe
This post on Http GET and side effects - in light of Google's Web Accelerator - made me think about something. I only just posted on this, but now I've read a bit more and thought about it. Here's what BitWorking has to say:
Let's start talking about you. And by you I mean all the web application developers out there that have been mis-using HTTP. Now I've been telling you over and over how to use HTTP correctly, how to build you web applications in a RESTful manner, and the consequences you could face if you didn't. Well, you didn't listen to me, did you 37Signals? Did you? Now Google releases their Web Accelerator and your application is broken. Apparently you used GET to delete items from Backpack and when Googles Web Accelerator pre-fetches that URI in you web app, items get deleted. Let's make this clear, Google didn't break your application, your application was broken, Google was just the first person to point it out to you. Do you feel the pain? Do you feel it?
Well, let's not get too self righteous or too far ahead of ourselves, hmm? Let's talk about something that's been an off and on topic in the syndication world for awhile - RFC 3229. That spec defines how a web server can answer incremental changes from a client. In the context of a news aggregator, that means only items that are new/changed since the last such request. In order to implement that on the server side, you'll need a dynamic feed, using header information in a GET request.
Well. The GET request effects a state change in the server with respect to the client in question. This is arguably a good thing for any conforming clients, since it reduces the amount of traffic that needs to be served. It's also something that Google's accelerator could render completely useless. I emphasize could - it's unclear to me whether the request sent by Google would include the requisite header info.
The point though, is this - not all client requests that result in a server state change are bad things. Heck, if they are we better get rid of 304, right now. The purists shouting from the rooftops about state free GET requests haven't thought this one all the way through.
Comments
[Bill de hOra] May 7, 2005 5:38:01.858
Well hang on there :) You can't be using the delta-encoding spec to build an argument for using GET to delete data. The purists have a real point here. The GWA is as far as I can tell, spec compliant, and the real point of GET is that clients are free from the consequences of side-effects incurred through link traversal. It's up to the server to take care of those side effects - that's how the technology is defined to work. And if you had to choose, I think data integrity beats bandwidth savings - it's a risky optimization ;) I'm more sympathetic to app developers than Joe is, largely because of the legacy of HTML Forms + Browsers + CGI will lead you naturally into doing stupid things unless you are an inverterate spec reader, which I think most developers are not. That legacy is what drives using GET for delete in 37Signals. Logout links are the classic antipattern. Bad client stacks have I think driven the bad design of server sided stacks, from forms to cookies to url design to using MVC where you possibly shouldn't be to servlets have a super method called doService. A lot of WS adherence to POST instead of PUT and DELETE comes down to that design history as well. It's a monster legacy.
Hmm, that's not the same thing
[Robert Sayre] May 7, 2005 17:27:05.352
"The GET request effects a state change in the server with respect to the client in question" No, the server's state is unchanged by those GETs. You're missing the difference between selecting a variant and changing the state of the resource.