Thanks to Sam Ruby for a heads up on a potentially nasty problem with Google’s new Web Accelerator, and badly designed REST applications. He linked to two sites that go into the details. The short version is that users of a specific web service were finding that they were losing data and after investigation, the service discovered that the Web Accelerator was the culprit.
The Web Accelerator is one of Google’s newest releases, and supposedly will help with the server-side backlogs that can occur when you’re accessing a site with a faster DSL or cable connection. How it works is that when you navigate to a site it ‘pre-fetches’ information by clicking on all the various links and, it would seem, caching the results.
All dandy (if confusing — we asked for this?) except for one thing: since this little deskside bot operates on a page under your name and authority at whatever site you’re at, if you’re at a web application that has links that do things such as ‘delete’ a web page or make some other form of update, the bot is just as happy clicking those links as not. Even if there is a Javascript alerts that should say, “Are you really sure you want to do that?”, it manages these behind the scene. Before you even know what’s happened, your data is gone.
Leaving aside that perhaps this won’t rival Google Maps for being handy, this bot does prove out a problem that people like Sam have been pointing out for some time — we’re using REST incorrectly, and because of this, we’re going to get bit in the butt some day.
Well, there’s a rottweiler hanging off some asses now, and it has “Google” on its name tag. (Uh, no metaformat pun intended.)
REST is an extremely simple web application protocol, and is what I’m using for my metadata layer in Wordform. Before I started implementing it, I researched around at what is needed for an application to be RESTful and the primary constraints are knowing when to use GET and when not to use GET. Really, really knowing when not to use GET.
You’re familiar with GET operations. In simplest form, when you search in a search engine, or access a weblog entry and there’s a URL with a bunch of parameters attached, that’s a GET request being made to the server. In this case, the parameters are passed as part of the URL.
Lots of applications have been using GET, not only to fetch information, but also to create or remove resources or make updates. However, what they should be doing is using methods other than GET, because this HTTP request type is only supposed to be used for operations that don’t have side effects. In other words: you can invoke the same service again and again and nothing will happen to the data with each iteration. Because of this, it’s also an operation that usually isn’t overly protected, other than perhaps a login being required to access the page or service. To the non-tech, it’s a link.
For operations that change data, we should be using POST, PUT, and DELETE. These requests are different in that all three have side effects. A POST is used to create a resource; PUT to update it; and DELETE to remove it.
These types of operations are associated with a certain sequence of events–you click some kind of Submit button and usually another page or alert box opens up that perhaps asks if you’re really sure you want to do this; you don’t see the parameters, and you don’t even necessarily see the service the request went to before a response page is shown. They are not links, and they don’t have the same global accessibility that a link has.
More importantly, potentially destructive agents such as Google’s Web Accelerator can’t do damage when you use the four REST commands correctly.
Today I tried to run my metadata flickr update application on my new weblog post and the flickr API is not responding. Since flickr is not using REST correctly –it’s using GET operations for events that have side effects–I am assuming that the web service is offline while the folks work on this. I haven’t been able to find an update anywhere on this, though, so this is my assumption only. Since I’m only using flickr for fetches, hopefully this won’t result in me having to change my code.
As for my metadata layer–it’s not as open as some of the applications that have used all GETs, but it isn’t fully RESTful either, which is why it won’t be released until it is–not when Google releases such a potentially harmful application. To be honest, though, my own pride should demand that if I’m going to use a specific protocol, I use it correctly.
Bottom line: Do not use Google Web Accelerator unless you know all web service applications you use are fully RESTful. If you do, you’ll most likely be unhappy as you watch your data disappear.
Two excellent articles on how REST works: Joe Gregorio’s How to Create a REST Protocol and Dare Obasanjo’s Misunderstanding REST: A look at the Bloglines, del.icio.us and Flickr APIs.
Oh, and don’t miss Phil’s Launch the Nuclear Weapon.
