REST (Representational State Transfer)

Not too long ago, I used to think REST (Representational state transfer) was a fancy name for sending XML over HTTP and using URLs as an API. I was peripherally aware of the theological debates surrounding REST, but I didn't pay much attention.

In SE-Radio's Episode 98: Stefan Tilkov on REST, Mr. Tilkov describes very clearly what REST is and why it's important.

REST defines a set of proven principles of software architecture for highly-scalable, loosely-coupled, distributed systems.

REST principles:

1. Identifiers: Every resource has an identifier. (URL) One thing they don't discuss is who's responsible for resolving the identifiers.
2. Links: One resource can link to another by its identifier. (hyperlinks)
3. Uniform interface: Every resource implements a common set of methods. (HTTP GET, POST, PUT, DELETE) (~=CRUD)
4. Representations: you interact with a resource via a representation; a resource can have more than one representation
5. Statelessness: there is no client specific session state. Move session state into resource state.

Like any good religion, REST has its high priests and scriptures:

• Old testament: Roy Fielding's thesis: Architectural Styles and the Design of Network-based Software Architectures
• New testament: RESTful Web Services By Leonard Richardson, Sam Ruby
• Roy Fielding
• Mark Baker
• Steve Vinoski who writes a nice column in the IEEE Internet Computing.

ReST vs. WS-*

The contrast is actually kinda interesting. ReST derives from an examination of what makes the web work. Since the web is arguably the most successful distributed computing system of all time, maybe it's worth while taking a look at the architectural principles that evolved along with it. In many ways, web services are the successor of CORBA and DCOM, which modeled computing as distributed objects. Many argue that distributed objects were a failure. Certainly, both CORBA & J2EE evolved away from sharing objects towards exposing facades. (For one reason, because the requirement that cooperating systems share an object model was unworkable in many situations -- application integration for example.)

The podcast pointed out something that was never clear to me before, and I think is a fairly important distinction between the architectures implied by WS and REST. In WS, you assign an identifier to an endpoint. The endpoint accepts requests. Each app has it's own API described in a WSDL (or CORBA's IDL) that specifies what requests it accepts. In contrast, any resource in a REST application has an identifier (its URL) and implements the methods of the uniform interface (GET, PUT, POST, and DELETE in HTTP). While each WS app has whatever methods it wants, REST limits the number of methods (or verbs). This allows generic clients (web browsers, curl) and promotes loose coupling. With the limitation on verbs, more prominence goes to the nouns - the addressable resources. Session state, for example, becomes resource state. If application-specific methods are needed, the four methods of HTTP can be seen as a base interface from which application-specific interfaces can inherit.

For my money, I think HTTP's methods probably could have been more clearly named. It's not obvious from their names what the difference in the semantics of PUT and POST should be. The HTTP methods almost map to the familiar CRUD (create, read, update, and delete) but not exactly. For example, PUT is an idempotent operation that inserts or replaces a resource at a particular URL. I'm not convinced the idempotency thing buys you enough to be worth obfuscating plain old CRUD.

As an aside, Mr. Tilkov mentions the MEST architectural style which seems to be an attempt to meld message-based architecture with REST. In MEST, all the meaning is in the message. The uniform interface becomes process(message).

They also discuss a few more nice aspects of REST:

• sensible (human readable, hackable) URLs
• standard response codes
• collections of resources are also resources, an instance of the composite pattern. For example, you might POST an order to a collection of orders.

Stefan makes an interesting point when asked about the utility of using web protocols within a company. His claim is that organizations internally increasingly resemble the internet. Organizations need loosely coupled applications to promote business flexibility.

So, OK, I guess I'm converted to a RESTafarian. At a gut level, I was never a fan of web services. They always seemed to make things harder than they should be. Maybe, I'm not completely converted, 'cause I think some of the criticism about what is and isn't truely RESTful gets a little silly. I like that Stefan take the pragmatic stance that engineers can adopt some or all of the principles as they see fit.

More Information:

• Stefan Tilkov's A Brief Introduction to REST can be found on InfoQ.
• Designing a RESTful Web Application