Blogger: Anne Thomas Manes
There's no one better to explain REST than the man that defined it. Roy Fielding gave a presentation recently at JAZOON 07, and the folks from BEJUG were kind enough to post a recording of the session on Parleys.com.
Roy described REST from a fairly technical perspective, and unfortunately he was a bit rushed in his presentation. (He learned at the last minute that the session was much shorter than he expected.)
I particularly like the way he summarizes the REST constraints. Plagiarizing his slide:
- Resources are identified by only one resource identifier mechanism
- Access methods (actions) mean the same for all resources (universal semantics)
- Manipulation of resources occurs through the exchange of representations
- Actions and representations are exchanged in self-describing messages
Hypertext as the engine of state:
- Each response contains a partial representation of server-side state
- Some representations contain directions on how to transition to the next state
- Each steady-state (page) embodies the current application state
I'm not quite so fond of the way he compares REST to SOA. First of all, it really isn't appropriate to compare REST and SOA. SOA is an architectural style that should be used for high-level system design, while REST is an architectural style that should be used for system implementation. (I discussed this last June in the blog entry SOA and REST operate at different levels of architecture.) And second, Roy is equating SOA with web services. Although a lot of folks use web services to implement services, that's simply an implementation decision. Any type of middleware can be used to implement services. (I discussed this topic in September in the blog entry When Technology Matters in SOA.)
Stefan Tilkov also posted an excellent discussion about the different architectural levels of REST and SOA, FAQ Entry: What's this REST vs SOA Debate About?
So when watching Roy's presentation, replace the term "SOA" with "WS-*", and the discussion will make a lot more sense.