RESTful application development has been receiving a lot of attention, especially as well-known public services have started to offer REST-friendly APIs.

From a design perspective, an interesting aspect of REST is that it replaces verb-oriented API elements, such as, say, getUsers(), with a set of HTTP operations on nouns, such as GET that returns a set of users, or DELETE to remove a specific user. By using the verbs of HTTP, RESTful applications provide a uniform interface, making it possible for any REST-friendly client to access and use any RESTful service.

One of the more complex issues in REST center around the PUT verb: By the HTTP specification's prescription,

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

This point is further elaborated in Bill Venners' interview with Elliotte Rusty Harold, Why PUT and DELETE?

In a recent blog post, RESTify DayTrader, Joe Gregorio provides a detailed description of idempotent PUTs. Gregorio's implementation centers around RESTifying an RCP-style Web service. In the process, he defines several RESTful collections. Idempotent PUTs are then implemented with the help of those collections, combined with a set of HTTP response codes:

We get a benefit from treating tickets [Editor's note: ephemeral objects created in the process of implementing a PUT] as members of a collection. Each has a URL, and even though we never store the unused tickets, we can still return a 200 for valid open tickets, and 404s for tickets that have actually been used (remember that we have to store them). We can return a 200 for valid open tickets since the server can validate the ticket and can then confirm that the ticket has not been previously used. We could also allow DELETE on a pending_order to invalidate them, and we could allow GET on the pending_order collection to retrieve a list of all pending_orders.

Although few browsers currently support the HTTP PUT and DELETE methods, Ajax client libraries can be used for those HTTP verbs.

What do you think of Gregorio's example of turning an RPC service into a RESTful service, and of his implementation of reliable HTTP calls?