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.