Resource-oriented Architectures

JJ follows up, in a comment here and on his site (*), on our discussion about the resource-oriented aspects of REST; I’m a bit late to respond, but here we go.

First of all, let me try to give a quick definition of REST as I have understood it (if you’re new to REST, a good place to start is the very nice introduction by Roger Costello; the reference work is Roy Fielding’s disseration). REST is an architectural style, and thus expressible with different technologies; the most important technology used to implement REST is HTTP. Let’s assume we’re doing REST on HTTP for the sake of the argument.

The first key idea is to have something called resources. A resource can be an instance of any sort of concept; it might identify a persistent, real-world entity such as a house that is to be mortgaged, something more virtual, but still persistent, such as an order, or something relatively transient, such as a shopping cart. The main idea is that you can identify a resource with a common addressing scheme (URIs in HTTP).

The next key characteristic specifies how you interact with resources, and in REST this is done using a uniform API. This means that all of the resources support a common set of operations; in the case of HTTP, these operations will be GET, PUT, POST, and DELETE. All resources are accessed by means of these common verbs, and all of the desired behavior needs to be expressed using these verbs only.

Another issue is that you access resource representations, which are transfered back and forth between client and server. Your server does not (need to) know anything about your clients; it’s stateless, and a client must not rely on the server to maintain any intermediate results in a conversation.

Finally, a resource representation can (and usually will) also include links to other resources, and when the client follows these links, it transitions into another state.

Of these characteristics, the uniform interface is often mentioned as the most important one; I don’t find this very convincing since I can easily build a uniform interface as a special case with a technology that enables me to create application specific interfaces (with the obvious downside of not being standardized).

But what is far more important to me is the first concept — the addressable resource. This is why I consider REST a resource-oriented architecture, as opposed to a service-oriented architecture. And that was the point of my original comment on JJ’s post — Paul Prescod uses the term “data-centric” to describe what I call resource-oriented, and ebXML BPSS (which I admittedly don’t know in detail) clearly does not follow this pattern.

JJ raises another issue: how to describe contracts in a RESTful application. The short answer is that you usually don’t, since the contract is already specified by HTTP and its verbs. The longer answer is that you could describe it either using prose in an HTML page (maybe even using RDDL? not sure), or even WSDL.

(*) I can’t find the document — I see the content in the RSS feed, but the link points to the wrong place. I’ll update once I am able to find it …