Santosh Benjamin's Weblog

Adventures with AppFabric, BizTalk & Clouds

Thinking about WS* and REST

with 4 comments

In a previous post I highlighted a great webcast by Scott Hanselman on OData and discussed the metaphor he used to explain OO and SO (the Librarian Service). I’d like to continue discussing that webcast and this time turn my attention to REST and WS*.

To paraphrase Scott’s explanation,” SOAP is great for (that kind of) asynchronous message passing with the appropriate level of transactional consistency and so on, but if you just want to get a list of books and walk around in the stack of books, should I be sending asynchronous request-response messages to the Librarian Service? That’s rather heavy. I just want to see some stuff. I just want to do a “GET”. That’s what REST is all about.

REST says “We’ve got this thing called HTTP with a verb called GET and a cool addressing scheme in the URL that lets me get stuff (and we I have some other verbs like PUT, POST and DELETE that map really nicely to Create, Read, Update and Delete. So if I want to do CRUD over HTTP, the semantics are already there. So REST is about retrieving resources and sometimes about updating/modifying them.

So if we don’t get dogmatic and ‘exclusive’ about how we want to approach the system, we could now implement hybrid systems where for the CRUD , we could use WCF Data Services and OData and for the areas where we need the security , reliable messaging and to interoperate with legacy systems some of which may be using the WS* spec (for instance if we are passing money around ), then we use the ‘traditional’ SOAP approach. Most of the time we try to create artificial divisions and ring-fence our systems and tie them all to a particular approach when we really should be implementing services in a way that is appropriate for the parties/systems/people that are consuming them.

I think the final statement there is worth repeating : we should be designing/implementing services in a way that is appropriate for the scenario and consumer.

A lot of the proponents of REST (but of course not all of them) tend to be dogmatic. “WS* is evil” is the usual mantra. That’s simply not true. Sure, it is complex. Once you get past the WS-I basic profile (and even that is not implemented by everyone), things are hard. But complexity of SOAP does not negate the necessity for it nor is it an argument for a “programmable web”. What if I don’t want the web (or the part of it where my system lives) to be programmable?  I want to expose services, but i want to choose the consumers and I mandate the contract. In, say a financial services domain, for example a Payments System, I certainly don’t want my customers details to be easily available over a “GET”. Heck, no! I want the appropriate headers, I want X.509 mutual certificates, I want the whole shooting match (otherwise my customer will shoot me 🙂 ) . But if I were to build say, an admin interface, where my user base is locked down and heavily authenticated, and if there was a scenario where they needed to drill down to look at payment patterns, then sure, GET would be fine, saves me having to define numerous interfaces just to retrieve different aspects of the same thing.

Anyway, this isn’t intended to be a rant. I’m excited about the potential of WCF Data Services and OData.  In the next post, we’ll examine one of the most interesting aspects of that webcast, namely a demo of a data service with absolutely no database which puts paid to the notion that WCF Data Services is about chucking your precious DB straight into the internet. Stay tuned.


Written by santoshbenjamin

September 5, 2010 at 4:56 PM

4 Responses

Subscribe to comments with RSS.

  1. Nice post. A good start guide to people biased towards SOAP 🙂

    Seetharam Raman

    September 8, 2010 at 7:12 AM

  2. My guess is that you have not worked with large scale projects in large organizations. If you have, these organizations probably did not have any sort of governance or enterprise architecture policies.

    If you are choosing whatever services strategy (WS*, OData, REST etc.) just randomly based on what you need you will have problems. I personally like a RESTful service approach (since it is not technology specific) (WS* in MS you are pretty much forced to use WCF) with a mix of WCF RIA/Data Services for transactional services.

    Bart Czernicki

    October 2, 2010 at 12:26 AM

    • Hi Bart,
      Thank you for your comment. I dont think we are disagreeing here. Random decision making is always going to land projects in hot water. Choosing a technology because it is cool or throwing another technology out because some aspects of it are complex arent good approaches but this happens all the time. I would think/hope that in the organizations where there is good governance, that the decisions are taken with the systems requirements in mind. As you’ve said some scenarios require a mix. You’ve used RIA/DataServices for transactional requirements and ‘regular’ REST for others. No debate there (at least from me 🙂 ) . i found the following post by Steve Jones quite fascinating : .


      October 2, 2010 at 8:56 AM

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: