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
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
Self-description and namespace mixing If I produce a
multi-namespace document, am I automatically importing the
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
A proposal of mine
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?
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
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,
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
“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.
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”.
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,
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
An interesting question would be, what would a late bound version of an SOA
look like? And wouldn’t this be worth pursuing?