The rain lashes against the window; the wind howls through the trees.
It is dark outside. Gusts of cold westerly wind sneak under the door
but are mercifully warmed before they reach my unshod feet by the
sterling efforts of a blazing fireplace. Coffee in one hand, Roy
Fielding's PhD dissertation on architectural styles and the design of
network-based software architectures in the other -- just another
evening in paradise, or, if your prefer, another evening reading my way
through a bout of torrential rain and freezing cold on the North
Atlantic coast.
It is not often that a PhD dissertation by an esteemed computer
scientist is cited as a sort of comfort food for consumption during
prolonged bouts of inclement winter weather. Such things are not
typically easy to read. Fielding's dissertation is an exception. It is
easy to read, erudite, and exciting at the same time -- a winning
combination for any type of factual presentation.
On the face of it, the dissertation does not seem to have anything to
do with XML. It is concerned with architectures for distributed system -
- not markup. It may, however have a lot to do with XML. We will get
back to this point in a moment. First, let's look at what Fielding's
work is about.
The dissertation starts by classifying the various architectural styles
that can be used to build software in general and distributed software
systems in particular. He gives the various common architectures
detailed names, digging beneath such generalizations such as
client/server to such delightful acronyms as LC$SS (layered client
cache stateless server).
The various architectural styles are evaluated against such criteria as
performance, efficiency, scalability, simplicity, modifiability,
portability, and reliability. Unsurprisingly, different styles have
different pros and cons. No silver bullet here, then.
The Web itself is then looked at through the eyes of this
classification system. Fielding coins a term for the point in the
classification system occupied by the Web: REST -- standing
for "representational state transfer."
Simply put, the REST architectural style consists of a set of named
resources. Resources communicate by transferring representations of
resources in a small set of standard data types. These communications
can be purely informational or can instigate actions to change the
state of resources.
In the implementation of the REST architecture that is the Web,
resources are known as URIs. URIs communicate by transferring
representations of resources in a small set of standard data types
(e.g., MIME) with standardized metadata (e.g., HTTP headers). The
communications can be purely informational (e.g., HTTP GET) or can
instigate actions to change the state of resources (e.g., HTTP POST).
The Web as practiced is not a perfect match with the REST architectural
style. In looking at mismatches between HTTP and REST, for example,
Fielding singles out cookies for special attention. Cookies break the
REST model by storing information on a per-site basis rather than on a
per-URI basis. Fielding bluntly states, "Cookie-based applications on
the Web will never be reliable." Oh dear. Fielding points out that one
of the reasons the Web is amazingly scalable is that it is stateless --
servers do not maintain session information on behalf of clients. Oh
dear.
Why am I wearing such a long face? Well, the reason is that if you
believe what is going on in the world of Web services, the Web is going
to be the basis for the next-generation distributed computing
environment for browserless, computer-to-computer communications.
This "Web as API" view is leading legions of software developers to
believe that the Web will provide the sort of things they associate
with programming APIs -- things like reliability, responsiveness, and
session management, to name but three. Having read the dissertation,
I'm having trouble reconciling this "Web as API" view with the REST
architecture. Is it feasible to implement the Web services vision on
top of the Web without violating the principles in REST, which made the
Web work in the first place?
But hey, this is all philosophical twaddle right? It will all work out
because we have a magic bullet! And that bullet is ... XML.
Oh dear. Yes folks, sadly but truly, even as we speak many of the
fundamental questions that need to be asked about the very feasibility
of what some people are envisioning as Web services are being swept
under the carpet in a headlong rush towards XML syntax.
Everywhere you look these days you hear talk about distributed systems
implemented on top of XML. There seems to be this notion that simply
expressing the data to be transmitted XML notation somehow will act as
a great leveler of all the architectural styles that Fielding
identifies so well in his work. "Just use SOAP" goes one common battle
cry.
It is as if in one fell syntactic swoop, pull, push, asynchronous,
synchronous, real-time, pseudo-real-time, fire-and-forget, once-and-
only-once delivery, end-to-end receipting, content-based routing,
publish/subscribe, and goodness knows what else seem to have
been "parked" for future consideration while we worry about the merely
syntactic issues that XML is so good at.
Well, I for one don't get it. I would be the first to agree that Big
Design Up Front is not a good idea, but gee, there seem to be some very
fundamental questions to be answered before we can sensibly digest
another boatload of XML standards in the area of Web services.
For anyone interested in the real issues facing Web services,
Fielding's dissertation is an excellent place to start and the REST
architecture a good common conceptualization of the architecture of the
Web around which to frame the issues.
