[PRL] RE: REST (fwd)

[David A. Herman]

Here's Anton's second response.

Dave

---------- Forwarded message ----------
Date: Thu, 17 Feb 2005 01:26:44 -0500
From: Anton van Straaten <anton at appsolutions.com>
To: Dave Herman <dherman at ccs.neu.edu>
Subject: RE: REST

You can forward any of the following if you think it's relevant.  Hope it's
not too rambling.  I may recycle this into something for public consumption.

> So, to a first approximation, could we say that Fielding's REST
> is basically just an abstract description of how the web works

Yes.  With some emphasis on which approaches are most natural for the web,
most web-like, and therefore most desirable.

> whereas the "extreme REST" is a rather stubborn dedication
> to retrofitting applications to fit the platform?

I'm not so sure about that.  When you say retrofitting, I tend to think of
modifying existing applications, whereas extreme REST advocates are also
talking about designing new applications this way, with the goal being to
achieve a more automatable web.

I also didn't mean to imply that extreme REST was a wrongheaded approach,
except perhaps in its choice to overload the term "REST" without drawing
clearer distinctions.

Service-oriented applications have their own special requirements, and I
think extreme REST is mainly a response to that.  The SOA space is very
immature at the moment, but people are developing SOA applications anyway.
Microsoft has been pushing SOAP pretty hard as the distributed messaging
infrastructure for SOA, but that's suspect for all the usual reasons,
including the fact that it does appear to be overengineered for many
purposes.

In this context, I think the extreme REST approach is not an unreasonable
one.  A big advantage of the approach is that you can create applications
which use it today, without requiring any particularly special tools.  From
a REST perspective, it's not essential to go crazy and create special
distributed messaging formats in the traditional RPC model, which is what
SOAP started out trying to do.  Instead, you can just deliver ordinary XML
over ordinary HTTP, and design applications to deal with that.  Nothing
stops you from designing high-level frameworks that abstract away from those
low-level details, though.

Constrasting this with SOAP is helpful to highlight some of the key issues.
SOAP addresses the question of distributed messaging by creating a new
messaging layer -- SOAP messages are all in a very specific format, which
are generated by SOAP libraries via a traditional API.  No-one generates raw
SOAP messages (e.g. their XML format) directly from application code, it
wouldn't make sense.

This is at the heart of the REST/SOAP debate: the SOAP message format is
essentially a fully encapsulated abstraction layer which applications are
only supposed to interact with via an API.  REST messages are completely
open XML data (typically) which applications are free to deal with as they
see fit.

One of the primary ideas behind REST is that it's intended to support a
compositional, pipe & filter approach to application building.  The Unix
command line is commonly invoked as a similar existing model.  One shared
feature between the two is the idea that it should be possible to compose
applications that otherwise have no knowledge of each other.  Both achieve
this by sticking to simple and open data formats: mainly text in the Unix
case, mostly XML in the REST case right now.

It's easier to see how a compositional approach would work on a wide scale
with REST and XML, than with something like the SOAP APIs.  Achieving some
of these things with SOAP is likely to involve transporting something a lot
like ordinary XML in SOAP messages, at which point the question becomes why
you need SOAP in the first place.

Of course, SOAP being of debatable utility doesn't make REST right, but I
think it's useful to compare the two.

> What I mean is, since hearing about all the work the PLT guys have
> done on continuation-based web applications, I tend to think of the
> web as a kind of complicated, distributed assembly language, and the
> frameworks people come up with (Cocoon, Seaside, PLT Web Server, etc.)
> are compilers from languages that are written the way we *want* to
> write them into this weird assembly. In this probably oversimplified
> view of the world, extreme REST becomes analogous to insisting on
> programming in assembly.

I agree that you can look at the mechanisms, like URLs and XML, as being
analogous to assembly.  However, there's a reason to want an application's
external protocols to be at that level: interoperability in the SOA
environment, where other clients and servers aren't necessarily under your
control.

There's no reason why a web "compiler" couldn't generate the necessary
RESTful URLs and XML from a higher-level application description, and I
suspect many REST folk would embrace something like that, if it wasn't too
foreign.

Something like PLT's web server, though, doesn't currently produce the right
sort of "target code" for the kinds of applications which REST addresses.
In the PLT approach -- and most other continuation frameworks -- sessions
are usually handled by holding first-class continuations on the server
between requests.  This raises the potentially major issue of server
affinity for requests.  At the very least, requests in a given session need
to be routed to the same server that handled the prior requests for that
session.

However, that's a poor solution from a REST perspective.  For a start, it's
not very scalable, in that sessions are bound to particular servers.  It's
also unreliable, in the Unix sense of not being crash-resistant -- when a
server process crashes, you lose your server-based continuations, which can
be unacceptable for some applications.  To address this, you really need to
be able to serialize continuations, which allows them to be persisted as
well as moved between servers.  (Of course, not every application needs to
care about such things, so this is also a question of appropriateness to the
requirements of the application.)

But even if you support both persistence and migration of continuations,
REST principles still aren't satisfied.  Stable URLs are very important to
REST, because they're supposed to name resources, which is important to
interoperation, especially over time.  Handing out lots of URLs containing
continuation identifiers isn't particularly RESTful, because the
continuations are by nature not permanent resources, and the URL names are
meaningless.  This certainly isn't extreme REST.

I'll ignore that for the moment, though, and look at other issues with
server-side first-class continuations in a truly distributed applications.
There are other problems with them, perhaps more obviously serious than the
lack of RESTful URLs.

In SOA applications, a client may be interacting with multiple servers
across different organizations.  This doesn't happen all that much right
now, but you do see it for example when a web store hands you off to a
different site to capture your payment info and process the payment.  The
idea with SOA is that this sort of thing will become much more ubiquitous in
future, and be used in more complex contexts than just paying an invoice.

In the invoicing example, the web store needs to communicate certain
information about the client's invoice, to the payment handling site.  In
many contexts, it makes sense to communicate that kind of information via
the client, rather than directly between servers.

Instead of setting up a three-way communication between two servers and a
client, in which one server is essentially saying to another "expect a call
from this guy, and here are his details", the client itself can provide all
the necessary details.  Conceivably, even something like confirmation of
payment back to the vendor could be communicated through the client, e.g.
via an encrypted certificate signed by the payment site.

The point is that server-based continuations aren't the only piece of this
puzzle.  At least sometimes, the (abstract) continuations take us from one
server, through the client, to another server somewhere else.
Realistically, we're not going to be doing that any time soon with
serialized first-class continuations of the sort we're familiar with, if
only because that would require standardizing a distributed, cross-language
continuation format.

What we want instead is a lowest-common denominator mechanism that will work
very widely.  This brings us right back to URLs, HTML forms, and XML of
various sorts, as one of the more viable and pragmatic options, whether or
not they're wrapped by a higher-level framework.

Motivation-wise, keep in mind that the above example is still a trivial
current-tech example.  Future SOA apps will integrate sites that don't even
know about each other in advance, and will often involve richer client
applications which have their own, non-trivial continuations.  Coming back
to the web-framework-as-compiler idea, an SOA-aware framework needs,
essentially, to be able to *export* continuations to clients and potentially
to other servers which are not based on the same framework, language, etc.

One can of course take the narrow view of only worrying about the
continuations within a single server, if you just happen to be involved in
developing the software for that server.  However, in the contexts I'm
talking about, that's not very interesting, since it does nothing to help
manage the complexity of the overall system.  Besides, when your server is
not controlling the overall system, storing continuations on the server and
handing out opaque URLs is likely to create problems for applications that
want to integrate with your server -- they can't synthesize your
continuation URLs the way RESTful URLs can often be synthesized, and so
clients are limited in how they can interact with you.

By contrast, if you create continuations as exportable entities which other
applications can understand, then your appplication becomes a more useful
player in a large network.

* * *

Speaking of richer client apps, have you seen the Mozilla Amazon Browser
(http://mab.mozdev.org/), which provides a rich client for searching &
browsing Amazon?  It gives some idea of the potential for SOA applications.
Imagine something like this that integrates information from multiple sites.
In that case, the client would be much more in control of the behavior of
the overall application, which affects the way the continuations work.

This kind of thing could be used effectively within companies with complex
supply chains, to do things like integrating product and inventory
information from any supplier, where their internal applications would know
how to combine information from disparate suppliers in a way that makes
sense to them, e.g. for the products they create.  If you generalize "supply
chain" to "value chain", so that you're not just talking about physical
product and inventory, but also about services of all kinds, then this
applies to just about any business, and explains why the analysis firms have
been waxing lyrical about how many billions the SOA space will be worth over
the next five years.

[Irrelevant bits snipped]