In an on-going series of posts titled The REST dialogs, Duncan Cragg “argue[s] the case for eBay to adopt a truly REST approach to their integration API”. In “Business conversations”, Duncan makes a businesses case for adoption of REST-style architecture.
Duncan explains, in a conversational style, to a fictitious eBay architect, that a RESTful approach is a simpler, yet more powerful, in architecting business processes than an SOA built using WS-* specifications. On the role of an application architect, he says
It's [his] job while [he is] designing [his] resource interactions at the application level: the resource-type or business level. Or maybe while [he is] making use of some existing resource types and 'resource-animating' code that does [his] business logic for you. Having WS-* only clouds and complicates this task.
“When you start thinking in terms of resources not actions, it all becomes much clearer”, Duncan states as he tackles aspects like Service Discovery and Description, Client State and Sessions and Business Processes in a resource oriented architecture (ROA). He states that
it's best to start with loose arrangements and established conventions; adding constraints, contracts and Central Control only where absolutely necessary. Ensure central control only over schemas.
Make your Enterprise 'mashable' and everyone will thank you. Expose the UUIDs and GUIDs of your data in URLs. Transform and enrich your data within standard content types.
On managing client state in such an architecture he warns that
[Any] Hidden state is a red flag. You know you're on the right track as long as you are exposing your statefulness in URIs. […] If you find yourself hiding state in sessions and cookies, or returning different data dedicated to that client from the same URI by setting no-cache, or if you tie up successive interactions through sessions, you are going down the wrong track.
He acknowledges that such an approach might be a hard sell in the enterprise, but states that it “more closely maps onto the reality of the way businesses operate and interoperate”.
REST […] naturally maps onto declarative business rules. When you switch from process-thinking to resource-thinking, you also switch from imperative thinking to declarative. Instead of coordinating the import and export of data from one hand-coded interface to another, you can just link it all up and expect everyone to dereference and recognise your data.
Do share your experiences in the adoption RESTful style in the enterprise and also do check out the original post and the series.