BT

RESTful Business Conversations

| by Dilip Krishnan Follow 0 Followers on Dec 16, 2008. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT