I have been working on a book for some time now with Raj Balasubramanian, Thomas Erl, and Cesare Pautasso (in alphabetical order). The title is SOA with REST and it is something I am pretty excited about being able to share with the world in the coming months. I'm sure that it will cause a few second takes on both sides of what has traditionally been a political divide between the REST and SOA camps, and I see this as a good thing. SOA with REST is intended to be a roadmap for bringing REST and SOA experience together into a cohesive conceptual framework and to allow adults to have adult discussions about what REST means to SOA and vice versa. I see the book as describing an architecturally pure yet also practical approach to the REST style and the SOA model.
Some attendees of last year's SOA Symposium will have gone home with a gallery of chapters from the book. For the wider audience we now have parts of our patterns chapter available as candidates in the catalogue at soapatterns.org. The set of patterns is partially based on trying to explain some of the REST constraints in a patterns language, and partly derived from Web experience. The published candidates are:
- Uniform contract
- A partial explanation of the whys and wherefores of the Uniform Interface constraint.
- Entity endpoint
- Why do we address resources in REST, rather than whole services as endpoints?
- Entity linking
- What is the point of hyperlinking in REST? (hint: Combine with uniform contract and entity endpoint to achieve runtime service discovery)
- Message-based state deferral
- How does REST ensure services are stateless between requests if it doesn't allow us to defer state to session databases or session management services?
- Response caching
- How does REST overcome the loss of publish/subscribe and other event-based communication patterns due to client/server and stateless constraints?
- Endpoint redirection
- How does the Web support services in deprecating old resources?
- Content negotiation
- How does the Web simultaneously support old and new service consumers as its uniform contract changes over time?
- Code on demand
- How does REST defer processing to service consumers, and allow consumers to be extended and customised as required by services?
- Consumer-processed Composition
- What does a typical service composition look like on the Web, anyway?
- Idempotent capability
- How does the web statelessly provide reliable messaging when there are no humans in the loop? (hint: idempotentcy is one half of the solution, and waiting until the last response has come back before you send another request that depends on the previous succeeding is the other half of the solution)
Benjamin