mark nottingham

Microsoft's RESTful Robots

Tuesday, 20 June 2006


A friend (who shall remain anonymous) pointed me to Microsoft’s announcement today regarding their foray into robotics, of all things. My eyes glazed over until they rested upon the Microsoft Robotics Application Model;

The term “REST” was originated by Roy Fielding. It abstracts, and to a degree, formalizes the Web architecture. REST builds on the notion introduced by Tim Berners-Lee that a URI refers to a resource and all interactions with that resource happens by exchanging state. One can exemplify a resource as a person and a picture of that person as a particular representation. Representations can change over time and be expressed in a variety of data formats. For example, a representation of a person can be rendered as a picture, a textural description, an audio clip, etc. The only way to interact with resources is through the exchange of state representations. The separation of state and behavior of a resource is a key component in achieving loose coupling between communicating components.

While many people think of REST as unique to HTTP, this is not the case. The principles of REST (and Web architecture in general) can be implemented in any number of ways but today HTTP is the only protocol that effectively allows one to think in terms of REST: It supports URIs and provide shared semantics for how to interact with resources.


Microsoft Robotics Studio Runtime brings together the REST and Web services worlds by adopting the REST model as its foundation but extending it with structured data representation and event notifications from the Web Services world. In order to do this, DSS defines an application model that incorporates the notion of event notification and structured data manipulation into a REST world and uses it as part of its service model…

Veerrry interesting. There will undoubtedly be debate on whether it’s necessary to fuse REST and WS-* together in this manner (especially in the face of things like APP and GData), but it does show that there are folks inside of MSFT thinking waaay outside of the Indigo box (there’s a pun in there somewhere, I’m sure).

Digging a bit deeper reveals who; So that’s what Henrik has been up to!

UPDATE: They’ve now published the WSAP document [word].


Yaron Y. Goland said:

In fact, Yaron almost ended up working for that team, but that’s another story. I should, as a good borg drone, point out that Indigo claims (haven’t validated myself) to fully support REST as a primary interface. Of course I’m not sure what they mean by REST since the term REST has become an object of religeous devotion rather than a rational definition but regardless I think they mean they have really great support for HTTP with all the basic verbs.

Tuesday, June 20 2006 at 2:56 AM

Dare Obasanjo said:

Of course I’m not sure what they mean by REST since the term REST has become an object of religeous devotion rather than a rational definition

The Indigo guys tend to just say POX over HTTP or just POX for short instead of REST for that reason.

Tuesday, June 20 2006 at 3:26 AM

Henrik Frystyk Nielsen said:


Impressive detective work!

With all due respect to my friends Yaron and Dare, the point here is of course not to be religious but rather to find an application model that maps well on to the robotics design space. It so happens that basic properties of the Web model like separating state from behavior works well in many robotics scenarios. However, we also need an event model which is why we added that as well as structured data manipulation.

We do have several papers covering our application model (thanks Mark for including pointers!) and I think you will find that we are not really concerned with whether to REST or not but rather to find something that works for the problem at hand.


Tuesday, June 20 2006 at 8:49 AM

Dare Obasanjo said:

I’m sure you’ll also find it interesting that Yaron’s current boss also came from the team that produced Microsoft Robotics Studio.

Tuesday, June 20 2006 at 12:59 PM

Duncan Cragg said:

I’m not sure what they mean by REST since the term REST has become an object of religious devotion rather than a rational definition…

REST needn’t be a religion! It’s an engineering discipline.

Just follow some sensible principles, demonstrated by a handful of practitioners:


and avoid the tangible costs:


Wednesday, June 21 2006 at 2:26 AM

Henrik Frystyk Nielsen said:


The “structured data manipulation’ is indeed covered by the INSERT, UPSERT, DELETE, etc. operations and also become an important part of our event model (you can see a description of this in [1]). It allows you to modify the state of a service at a very fine grained level which is necessary for many applications to effectively use services at this level.

Henrik [1]

Wednesday, June 21 2006 at 8:30 AM

Mark Baker said:

“It so happens that basic properties of the Web model […] works well in many robotics scenarios”

Funny, that. It seems to work in a whole lot of scenarios. It’s almost like it was designed that way! 8-)

But did you mean to say “separating state from behavior” there? Because in all my Web work, behaviour and its associated state almost always remain encapsulated together within a resource. For all but the most trivial of apps (those with no resource state), I believe REST requires this due to the stateless constraint.


Wednesday, June 21 2006 at 9:38 AM

Duncan Cragg said:

Henrik Frystyk Nielsen (if you’re still watching!):

I printed off and read the WSAP doc, but couldn’t find an explanation of one of the two features that you found wanting in HTTP: ‘structured data representation’ and ‘structured data manipulation’.

Is this described elsewhere? Or is it in some way implied by the extra message types such as INSERT, UPDATE, REPLACE, DELETE, but left up to the service to define in detail?

I agree that HTTP needs events and Publish-Subscribe, by the way…

Wednesday, June 21 2006 at 12:27 PM

Henrik Frystyk Nielsen said:


A fundamental difference between WSAP and WebDav is that PROPFIND and PROPPATCH methods are manipulating metadata on the resource and not the resource itself. In WSAP, we only manipulate the resource (which of course has a URI).

Another big difference is that in WSAP we let services hook up as partners which means that they easily can leverage each other. That is, in WSAP a metadata resource would simply be a partner service which you can manipulate exactly the same way as any other service.

An example of how powerful this is is how we handle subscriptions: subscriptions are nothing but pieces of state describing the subscriber and maybe a filter used in the subscription to specify the notifications the subscriber is interested in. No cookies or hidden state anywhere and the code for handling it is small.

Btw, this is all used throughout the Robotics Studio; you can see a screen shot of how often we use partners in [1], figure 6. If you install the studio you can actually inspect the Subscription Manager partner service to see who has subscribed to an individual service.



Saturday, June 24 2006 at 9:48 AM

Henrik Frystyk Nielsen said:


By “separating state from behavior” I mean that in the Web model the state is public but the behavior is private. That is, by doing a GET on a service you get the state but not the behavior.


Saturday, June 24 2006 at 9:56 AM

Nick Gall said:

I really like what I see in WSAP. Like GData and just plain Atom, it too points in the direction of a more constrained form of REST operations and data structures, which is a good thing (since REST is based on the imperative of a small set of common operations across endpoints and intermediaries). What may be very unfortunate though, is that Microsoft is in the process of patenting WSAP. See . – Nick

Tuesday, July 25 2006 at 8:00 AM