The first problem is to sort out the terminology. There are many
ways of classifying services, and we're introducing two more in the
book: "Resource-Oriented Architecture", which I've mentioned before,
and "The programmable web", which is a way of saying "web services" without implying Big Web Services, or even saying the word
"services". We got the latter term from the excellent programmableweb.com. (We also introduce "Big Web Services" itself, which is a way of saying "web services" and implying only the SOAP/WSDL/WS-* stack, but I think I'm going to use that term a lot more in these entries than in the book.)
The main work thing I did today was draw diagrams: a taxonomy
and Venn
diagram. Don't worry, they'll be redrawn by real graphic designers
before they're printed in the book. One or both might make it in; the
Venn diagram is simpler but the taxonomy has examples and chapter
references.
Both diagrams show two decisions I've made for the book: first, we
draw a distinction between Resource-Oriented and Service-Oriented
architectures. Second, we define HTTP+POX as a hybrid of the two
architectures. The former because it's not useful to pit a technology
against an architecture (as in "SOAP vs. REST").
The latter because
the web services described as HTTP+POX, the ones that are
kind-of-but-not-really RESTful, tend to deviate from REST in the
direction of RPC and the Service-Oriented Architecture (rather than
having no architecture at all, which was what I expected). Examples
include the Flickr API, which includes explicit method names
("flickr.photos.search"), and the del.icio.us API, which has special
URIs that you GET to invoke particular methods ("/posts/delete").
Some interesting edge cases: almost all web applications can be
considered HTTP+POX web services. They're usually not all that
RESTful, but they take standard HTTP requests with non-fancy entity
bodies, and serve a non-fancy XML dialect (HTML or XHTML). This is how
libraries like WWW-Mechanize look at the web.
In fact, I suspect the combination of URI- and RPC-based
architectures to form HTTP+POX comes from our experience writing apps
for the human web. You can't do nontrivial REST in a web browser
without Ajax. HTML forms only support GET and POST, they don't let you
set request headers, and they have hard-coded destination URIs (this
is why URI
templates are going to be great).
I used to think that, while the lack of PUT
and DELETE was lame, people who obsessed about those methods as a
determiner of RESTfullness were just being pedantic. But the ROA/SOA
classification shows why it's important: if you have to overload POST,
you end up creating extra URIs which the client POSTs to in different
circumstances. This puts you well down the road to the RPC model. Your
URIs no longer point to resources; they point to procedures you can
call by POSTing. It's natural to keep following that model when you go
from writing a web app for browsers, to writing a web service for
computer programs.
Another edge case is that a website full of static pages is
technically a RESTful web service. It's composed of resources (files),
each with one URI and one representation (the data in the file). Each
URI correctly supports a subset (GET and HEAD) of the uniform
interface. This is how libraries like Beautiful Soup look at the web.
If you look at the Venn diagram you see that the entire
human-visible web (static websites and web apps) is part of the
programmable web. This is quite intentional. People were programming
to the web long before anyone started talking about "web
services". It's dirty work because the human web wasn't designed with
software clients in mind, but sometimes it's the only way to get the
data.
There's one thing in the diagram I'm not clear on. It might be a
minor point or it might be an important aspect of our definition of
HTTP+POX. The question is whether there are web applications that are
so RPC-oriented they cross the limits of HTTP+POX and move in
on the architectural turf of SOAP/WSDL services. I drew the Venn
diagram with web apps that were neither REST nor HTTP+POX, thinking of
really monolothic web apps that only expose a single URI, and do
everything by POSTing to that URI.
The "POX" in HTTP+POX basically means "no SOAP", but what
specifically don't HTTP+POX people like about SOAP? Is it the
complexity of the SOAP message itself? Plain old XML can get pretty
complex too. Or is it the fact that the SOAP message contains
information (like the method name) that they think should go in the
URI?
There are also, as one emailer pointed out, problems with calling anything a "web service" if we're drawing distinctions between a "service-oriented architecture" and something else. I'm not sure what to do about that. I'm tossing around the idea of switching that label to "RPC-oriented architecture", but I don't want to introduce yet another term of art. Sun Nov 05 2006 20:12 Taxonomy of the Programmable Web:
As I've learned more about REST (including formulating the ROA) I need
to go back and rewrite the first few chapters. This entry is part of
my attempt to document what I've learned since then. As I write these
entries keep in mind that I'm not any kind of expert, I'm just a guy
who decided to figure out REST and write a book about it. So if you
disagree or think the something is called the wrong thing, leave me a
comment or email and we'll figure it out.