mark nottingham

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.

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.

Mark,

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.

Henrik

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

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:

– http://duncan-cragg.org/blog/post/2006-what-now-how-awards-rest-protocols/

and avoid the tangible costs:

– http://duncan-cragg.org/blog/post/strest-service-trampled-rest-will-break-web-20/

Duncan,

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] http://msdn.microsoft.com/robotics/getstarted/prgmmodel/default.aspx

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

Mark.

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…

MNot,

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.

Henrik

[1] http://msdn.microsoft.com/robotics/getstarted/prgmmodel/default.aspx

Baker,

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.

Henrik

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 http://www.furl.net/item.jsp?id=10617234 . – Nick