Web Things, by Mark Baker

And now for something completely different …

I thought it might help my cause for me to admit that I’m only human (yes, I’m not really a know-it-all!), and that there remain things about REST and Web architecture that I don’t understand (including those things that I don’t even understand that I don’t understand 8-). Here’s my current list of things I know I don’t grok.

Can I do PUT with POST RESTfully? I go back and forth on this one all the time. At first glance, the answer seems to be yes; that it should be possible to “submit data” with POST semantics, but using a mandatory extension (ok, so it’s M-POST) to indicate the extended intention of “state replacement”. But when you dig a bit deeper, you wonder if this is equivalent to tunneling; that the extended intention of PUT-via-POST provides visibility into the terminal state of the resource, which seems to be a no-no from a REST POV. I won’t even bother you with the wacked mental model I have of this issue, except to say that it involves residues.

Self-description and namespace mixing If I produce a multi-namespace document, am I automatically importing the entailments of those namespaces? Dan Connolly says yes (at least for RDF Schema), and I disagree with him. But I lack the background in this space to be able to convince Dan (or even myself, for that matter). It’s just a hunch at this point, but the issue has very important consequences, especially to REST which requires self-descriptive messages.

A proposal of mine was recently accepted by the RDF Core WG which IMO, will help explain what RDF is for to a lot of people who don’t yet understand the important role it plays in the World Wide Web project. I believe this because I’ve used the RDF it permits, to successfully explain what RDF adds over vanilla XML to Exec types.

Consider the following. Is it XML or RDF?

<Person xmlns="http://example.org/foofoo/">
  <name>Mark Smith</name>
  <age>55</age>
</Person>

Answer? It’s both. Depending upon which media type it’s described with, it means different things.

To an XML application that isn’t hardcoded to know about that language, it’s an almost entirely opaque blob, except for the namespace.

To an RDF/XML application that isn’t hardcoded to know about that language, it knows what the XML app knows, plus;

• that there exists a resource of type “http://example.org/foofoo/Person” someplace, with properties “http://example.org/foofoo/name” and “http://example.org/foofoo/age” with those values
• that additional properties can be added without impacting the meaning of the former interpretation, i.e. potentially breaking some application somewhere. An XML app can’t assume this; it might be breaking its validity against some schema someplace
• various other possible syntactic additions or modifications which can be used to extend the current semantics in a backwards compatible way, if desired.

This is the value of partial understanding.

I’m sure everybody’s seen the Amazon/Microsoft announcement about buying books through Powerpoint by now. Did you notice this bit?

The solution, called Amazon.com Research Services for Microsoft Office System, will be available for download in the Office Marketplace at no additional charge later this fall.

Oh goody, so now I’ve got to download a new app every time somebody integrates their services with Microsoft’s?

If you can’t do O(N) or better, go home.

Here’s an interesting project, Sensor Web;

Sensor Web is a web-centric, open, interconnected, intelligent and dynamic network of sensors. It presents an entirely new vision towards the way we deploy our sensors, the way we collect the data, the way we fuse and distribute the information.

Alright, I thought, some Web fans who aren’t afraid of tackling the big integration problems. Upon further investigation however, I discover (in a report titled “An Web-based Distributed Geocomputing Architecture for Smart Sensor Webs” no less) that they’re not using Web architecture, they’re using Web services. Hey, if they want to knock themselves out trying to tackle that problem given the known integration problems with Web services, that’s fine. But doing it while saying it’s “Web-based”, is misleading and harmful, especially to those who might use the Web to solve the same problems.

Mark Nottingham responds to my suggestion that “REST = SOA + late binding”;

[…] While I see the truth in this, I think it’s pretty orthogonal, and it’s not that compelling for most SOAish folks. This is because their use cases are machines talking to machines, not people talking to machines. In Web browsing, this is great, because people are smart enough to look at the late-bound semantics in a representation and figure out what they want to do; machines aren’t, yet.

Hmm, I think we might not be in synch about “late binding”. Without getting into the nitty gritty of it, which I admit eludes me sometimes, perhaps we can just look at the use Roy makes of the term;

This abstract definition of a resource enables key features of the Web architecture. […] it allows late binding of the reference to a representation, enabling content negotiation to take place based on characteristics of the request.

“Late binding of the reference to a representation” refers to GET; that any reference can be turned into data without dependencies on any centralized component. As a comparison between the SOA and REST approach, consider an identifier for a purchase order; REST would use a URI, “http://example.org/po/928340823”, whereas an SOA approach might use just “928340823”. Turning the former identifier into data, no matter where its discovered, requires simply invoking GET on it. Turning the latter into data cannot be done without a dependency on some central component that turns purchase order identifiers into data. This is why Web services need centralized registries like UDDI.

Hopefully this sheds some additional light on what “REST = SOA + late binding” means. Another interpretation could be “REST = decentralized SOA”.

In a report on Web services tools, PC Magazine‘s Robert P. Lipschutz writes;

Data-based strategies such as Roy Fielding’s REST (REpresentation State Transfer) replace SOAP and put the content, Uniform Resource Identifiers (URIs), and XML at the center of the equation. It’s too early to make the call on REST, but don’t rule this option out.

Doug, anticipating my response, promptly responds.

He brings up the “identification vs. location” issue, which I agree remains a point of contention between many (though the Web wizards are all in agreement on this one, at least 8-). But we’ve already been there, and I don’t think I could explain my position much better than I did there. So I’ll concede that point for the moment so we can move on to an aspect of architecture which I feel is more important in determining the degree of loose coupling; late binding.

REST uses late binding, as REST clients are developed to a system-wide abstraction; the resource. As an example of what this enables, a RESTful client can get data from any RESTful server. SOA cannot do this; a constrained interface is required for this, whether in a RESTful manner or not.

FWIW, in these terms, one can look at REST as the natural evolution of SOAs on the Internet; SOA + late binding => REST

Another excellent piece by Adam, this time on disconnected operation. He writes;

This model is profoundly different than the normal browser.

Well, different, but not “profoundly” different. But keep in mind that REST is more than just what is seen through a browser. It’s simply data transfer.

What he describes there is an architecture which sounds an awful lot like REST and “REST + additional constraints” to me, where the additional constraints would include things like resources are queues. Obviously not all resources would be queues in the system Adam describes, which is why you’d need two styles; vanilla REST, as well as REST with the queue constraint.

Doug Kaye writes, in reference to a list which places REST before SOA;

It also tracks the scales of tight-to-loose coupling and the availability of supporting technologies.

(suggesting that SOA is more loosely coupled than REST)

I don’t have much of a feel about how loosely coupled “Orchestration” is, but I do know that REST based services are more loosely coupled than SOAs. Whether or not you believe that REST can be used for machine-to-machine communications, I think it’s pretty clear that REST uses late binding, while SOAs do not, since REST constrains the interface. Amoungst other things, this means that any agent can exchange data with any service, past, present, or future. You can’t do that with SOA, because you don’t know the interface that future services might use to exchange data.

An interesting question would be, what would a late bound version of an SOA look like? And wouldn’t this be worth pursuing?