REST: Is it the Next Big Thing?

Blogger: Anne Thomas Manes

The APS team has been involved in a vigorous debate about REST for the last two months. Certain members of the team contend that WS-* has become bloated, unwieldy, and overly complex, and they fervently believe that we should not be recommending it any longer. Our resident RESTian also cites the fact that WS-* has no contraints, and therefore there's no way to ensure the properties and characteristics of applications built with it.

So if WS-* is a tragic mistake, does that mean REST is the next big thing?

Perhaps so. Vendors like IBM and Microsoft are starting to make major investments into technologies and frameworks that facilitate development using the REST architectural style. But for the moment, a steep learning curve and the dearth of available frameworks will stymie adoption. (For those looking to get started with REST, I recommend RESTlets.)

REST is not simply technology--it's an architectural style that's fundamentally different from they way most developers design systems today. It requires a noun-oriented approach to designing systems rather than one based on verbs. I know quite a few people that have been studying REST for years who still struggle with RESTful design practices. Understanding the basics of the style is easy. Truly groking it and being able to apply it to real-world situations is much harder.

Here are the basics:

• It is a resource-oriented style of design
• Every resource is addressable via a URL
• Every resource has a uniform interface
• State is exchanged via representations
• Messages containing representations are self-describing
• Interactions are stateless
• Representations reference related resources via hyperlinks

Note that REST is not the same as "plain old XML" (POX). POX refers to the format of a message payload, and it says nothing about architectural style. It just says that you don't wrap an XML message with an XML envelope (e.g., SOAP or Atom). More to the point, not all POX applications are RESTful, and not all RESTful applications are POX.

Likewise, REST is not the same as HTTP. HTTP is an application protocol. It's middleware, not an architectural style. It just so happens that HTTP is the only application protocol that fully supports the REST constraints. But a developer isn't forced to adhere to those constraints. In fact, not all HTTP applications are RESTful, and developers frequently use POST to tunnel method invocations (verb-oriented style). Also note that REST doesn't mandate HTTP, but it is the only standard protocol that implements REST constraints.

For those interesting in learning more about REST, I encourage you to sign up for Pete Lacey's half-day workshop, REST Easy, at Catalyst on Tuesday, June 26, 2007, in San Francisco.

Comments

[Mike Pittaro]

Anne,

It's nice to see an accurate description of REST as an architectural style rather than an API or some other simplification. This opens up the opportunity to frame the debate in terms of application architecture. The true debate is between REST and RPC (including Corba, DCOM, and WS-*) architectures.

One could argue REST *was* the next big thing, as seen in the success of the Web. However, the reference implementation has been primarily user to machine interactions. It seems the next big thing is really 'REST for machine to machine interactions'. We're beginning to see a more REST adoption in this area, and the use of standards like Atom and RDF is helping.

[Javier Cámara]

To me, this does not make sense. WS-* may have a number of overcomplexities, but on the other hand REST is bare bones. Lots of things have to be made for REST to get to the state WS-* is now.

All I want is INTEROPERABILITY, really. I really do not care about whether it is WS-* or REST. But since I see WS-* really far much advanced than REST, I see changing now to REST is going backwards some 3-4 years.

Why? Because some religious-like belief? The main point lying behind REST is it that it is more elegant. Any real benefit out there that can be justified e.g. to a Sales Manager?

I do not see the point at all.

[Alex James]

Anne,

I couldn't agree more "REST is not the same as HTTP" infact I have a rant about this very topic on my blog...

Alex