There was quite a bit of REST chatter at Øredev last week.  I sat in on the REST in Practice tutorial by Ian Robinson and Jim Webber (if you have not read the book they co-authored, then do – it’s really well written).  There were a couple of things that these two guys cleared up for me, in the tutorial and in conversation during the week.

Application state is in the head of the consumer, not the provider of the resources.  This suggests that we should be able to recompute the state of application at any time.  If we can recompute the application state, then we don’t need to explicitly implement the entire application state machine in the provider, nor the client.

You may start off with modeling an application state machine on paper and discover the life cycle of resources.  Implementing this is then simpler because we are only need to implement the lifecycle of the resource, not the entire application state.  The way the consumer drives the state machine is just be reacting to available transitions in the representation of a resource.  Now you give the provider the freedom to change the application state machine and the consumer will react to the new state machine by discovery. That is significant.

Use hypermedia to refer to yourself. This came up in the tutorial because I objected to a resource including a hypermedia link to itself, regardless of its state.  To me, it seemed to have little value because you already have the representation of a resource in a particular state, so why include hypermedia for itself.  For example, this is what a resource will look like without a link to self.

<Order>
  <id>823763</id>
  ...
  <links>
    <link rel="pay" href="http://example.com/payment/823763"/>
  </links>
</Order>
Now, if I want to GET the original order resource, I would need to know that there is some URI that includes the id of the order.  And, so, we end up publishing a URI template such as
GET http://example.com/order/{id}
If we include a link to self, then the representation looks like this.
<Order>
  <id>823763</id>
  ...
  <links>
    <link rel="self" href="http://example.com/order/823763"/>
    <link rel="pay" href="http://example.com/payment/823763"/>
  </links>
</Order>
Look Ma!  I don’t have to expose a URI template anymore.  It’s all discoverable.  That is significant.
REST support in WCF is heading in the right direction. I also listened to Glenn Block’s talk on his team’s work on HTTP and REST support in WCF.  It’s still early days but I think they are paying attention to experts in this space and giving priority to the developers that will use it.
In the past you would have to map a very specific, template based HTTP GET operation to a method like this (excluding the additional endpoint configuration too!)
[WebGet(UriTemplate = "{id}")]
public Contact Get(string id, HttpResponseMessage resp) { ... }
What Glenn showed was a method signature that resembled the HTTP operation on the resource.
public Contact Get(string id, HttpResponseMessage resp) { ... }
Sure, it’s using a lot of convention over configuration to get rid of the attributes.  Now that may not seem like a big deal, but I do think that it is moving the HTTP abstraction down to a level that is more resource friendly.  When you are building a RESTful architecture, then you do think quite naturally in terms of the resources and their allowable HTTP operations for obtaining state or triggering a state transition.  By moving away from mapping HTTP operations to a service contract, it introduces the necessary mental shift from RPC to Resources.  And that is significant.
Share this:
Twitter
Facebook
LinkedIn
Like this:
Like Loading...


	
Related