The simple story of why I like REST

So I've been dabbling with REST (Astoria among other things built on .NET 3.5).  I've been reading the stuff on Steve Vinoski's blog, and actually have had some good conversations with Sam Gentile  (and one tonight with him and Gar) the last few days about the subject.

When I read Steve Vinoski's blog post tonight - it hit it home for me again (this is the story I told Sam and Gar over drinks about why I like REST).  I feel like REST actually gives me way more architectural guidance about how my service should be built than SOAP.  With SOAP  I have Actions (which generally in WCF map to methods) and messages, but there isn't any *Zen* or guiding principal for me for building a service.

With REST - the guiding principal is the URI.  Take BAM for example from BizTalk - I talked about building a RESTful API on top of BAM.  In BAM I'd have a URI - http://hostname/BAMAPI/

If I hit the http://hostname/BAMAPI/ with a GET - I'd get a list of all the registered BAM Activities.  If I hit the URI - http://hostname/BAMAPI/ActivityName - I'd get all the completed instances of that activity.  If I wanted to add a new activity instance I'd do a PUT to http://hostname/BAMAPI/ActivityName/{ActivityId} where the {ActivityId} would be the unique key for my activity.  If I wanted to update that activity instance I'd do a POST to http://hostname/BAMAPI/{ActivityId} and I'd put the new data in the body of the Http Request.  I could go on and on about how this would work - but the point is - REST actually gives me guidance on what this service should *be*.  SOAP give me a *how*.  REST gives me a much more rational model on what my service should do and *why*.  And since I understand the web, and I understand URIs - it all really just makes sense.

This is probably the closest I will ever get to an "architecture" type post (I am sure it is woefully inadequate next to a Steve Vinoski or a Tim Ewald) but nonetheless I felt I had to let it out.

      Comments [0]