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”.