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
  (and one tonight with him and Gar)
the last few days about the subject.

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

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/

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
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.

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.


Check out my BizTalk
R2 Training.