GET, POST, PUT and DELETE in REST
No, I’m not yelling in the title. I’m just following up on Dare Obasanjo’s post about misunderstanding REST: A look at the Bloglines, del.icio.us and Flickr APIs. Dare’s complaint is that these services all have URLs that have side effects via HTTP GET. This is an interesting distinction to make.
I just set up a new Drupal installation, and I’m reminded of Drupal’s cron.php. cron.php runs whatever periodic maintenance tasks are needed. In other words, it changes data. But, you really want to use GET in that case, because it makes it trivial to add a wget crontab entry to ping it periodically.
My own app keeps does housekeeping as links are clicked, which is far easier via a GET than to rig up a POST via JavaScript. Maybe the difference here is whether or not one is making a claim of a RESTful interface. Or maybe the difference is how caught up in the semantics of it one is. Josh Alen has a good comment on this:
people chose between GET and POST based on other critera than suggested in the Fielding paper
I think this is on target. If you’re conciously providing an API for the public to use, following the RESTful standards that Dare mentions is worthwhile, because it helps with the principle of least surprise. But, you also need to look at the overall convenience of what you’re doing… if you have a good reason to bend the rules, do so and make sure you document it. If it’s truly a good reason for rule-bending, it shouldn’t really take people by surprise or throw them off.
This makes me think of the general notion that APIs are a user interface for developers. In Swing programming, to add a widget to a window you had to do this:
frame.getContentPane().add(somewidget)
This is the “correct” thing to do, because the JFrame object itself is not actually a container for UI widgets. But, it has a container: the content pane. Correct or not, it was annoying. Java 1.5 now allows you to do this:
frame.add(somewidget)
Though it is less “correct” for the architecture, I think this is more inline with what programmers expect and want to do with the API.
I don’t know if this is the case with the Bloglines, Flickr and De.licio.us APIs, but my main point is that there are times when user experience is worth more than “following the spec”.
Yeah, it really all comes down to if you’re claiming to have a true REST interface. I like the modified REST interfaces used by the places you list above.
If the API is only being used behind the scenes then the modified REST API’s are alot easier to work with. I just put together a GET request and run with it. No messing around with PUT’s and all. I think it makes it alot easier to document and explain to other developers as well.
I don’t know, it’s not just REST. This behavior is a “SHOULD NOT” per RFC 2616 [1].
If you know that your user agent and your usage scenario is the only one that matters, then I guess you could do whatever you want. You aren’t using HTTP for its interoperability traits in that case anyway. Break as many rules as suits your needs.
If you want to move through proxy servers, work correctly with spidering robots, etc. where you have to abide by generic semantics then non-safe/non-idempotent GET requests are a pretty bad idea because they break a contract w/ the user agent.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1
You’re correct that you do need to take your operating environment into account. As, I believe, Dare points out in the original article, these services are largely working in authenticated realms. So, you don’t have the problems of spiders (though I guess you could have proxy server problems).
Interestingly, many wikis break this contract to some extent as well, with the “Edit” links on the page. The Edit doesn’t happen until you POST the new contents, but many wikis will lock the page at that point. I’m assuming they use robots.txt to keep Google from locking every page.
Tagsurf’s API ( http://tagsurf.com/docs/api/ ) is actually a RESTful implementation even though I based it on the Flickr API. GET doesn’t modify state, POST is used to create, PUT to update and DELETE to delete. At times though it’s annoying to test since I actually need to have a client implementation of the method to test (i.e. just using a browser isn’t sufficient).
So, the question then: is the benefit worth the tradeoff in ease of testing? For some apps, I’m sure it is. But, if you can speed development by being able to point your browser there and see what comes out, maybe that’s a bigger win.
“i.e. just using a browser isn’t sufficient”
Anthony, try getting your hands on Curl. You can drive it easily from scripts or ant files.
Speaking of browsers, all the rot starts with HTML forms, which mandates GET|POST only. I really do think you can trace the entire problem from there. Not just GET with side effects, I’m including POST obsessed webservices technology as well.
It’s amazing how many stacks now are essentially two verb by design - we came across a J2ME use-case in the Atom WG - that’s probably hundreds of millions of clients.
I think the “do it in a browser” idea is the reason Tomcat allows you to do things like delete webapps using a GET. When you step back a bit, that’s just nuts. But we’d be lining up to chew someone out if they wrote Java code that set the User field after calling getUser
I haven’t tested thoroughly, but my experience is that other methods (PUT and friends) work with XMLHttpRequest. Try it out.
I agree with Bill — there’s no good reason to use wget when curl is available and provides vastly more flexibility with regard to the variety of HTTP requests command-line applications can create.