RESTful Web services and DAL
Norman Gray
norman at astro.gla.ac.uk
Wed Mar 14 03:16:20 PDT 2007
On 2007 Mar 14 , at 04.47, Doug Tody wrote:
> I'll attempt to summarize our discussions to this point.
Excellent -- thanks Doug -- this provides usefully concrete things to
agree and disagree with.
Despite all the gags about REST `theology', I don't think anyone is
trying to sell salvation here.
REST isn't about theoretical discussions, but about making a group of
intensely practical (or `real world') observations about the observed
architectures of stable and usable services. Technique A appears to
be associated with robust services; technique B with brittleness;
thus, use technique A.
> My conclusion is that while REST is a very powerful and fundamental
> architectural style, similar to the concept of a Unix file, the HTTP
> protocol also includes GET with parameters for good reason
Indeed, although I think that the `good reason' might have been that
they seemed like a good idea at the time, though they're actually the
best tool in fewer circumstances than one might expect.
> Nonetheless, a GET (or POST) with parameters [...] is analogous to the
> method/operation/function in an object interface in any other
> technology.
I think that a REST contention would be that this is a tempting but
poor analogy, that could lead one into writing the sort of against-
the-grain code produced by the programmer who will write Fortran in
any language. That is, if you think of GET as a way of doing remote
method calls -- a sort of nasty, clunky, RPC -- then you risk
producing a service that will introduce brittleness sooner or later,
when this service is composed with other ones. You can avoid this --
manifestly -- but both the author of the service and its users have
to work harder, and think about side-effects, and idempotency and so
on. If the URL is manifestly just a name, on the other hand, then
you will produce a service with these desirable properties, without
having to think much about it at all. This is a bigger deal than it
might sound, as it's about designing interfaces (just as one might do
with a GUI) which prompt users/clients to intuit the correct behaviour.
> REST has no use for a parameter-based GET since the latter is an
> operation or method performed upon some object, and conflates actions
> with resources.
I think there is a role for URLs with parameters in a REST-style
interface (others disagree, I know). However it's rare, because it
encourages this false analogy with procedure calls, and because of
the problems which Guy describes in his earlier message. At the same
time, I don't believe that this is the core issue, and that arguing
about whether SIAP cutout URLs are RESTful or not is possibly a bit
of a blind alley.
Doug, in an earlier message:
> What may not fit into the REST model well is asynchronous messaging.
> Perhaps this is just a GET where we hold the HTTP connection open and
> stream messages periodically?
Others have responded to this. I'll simply add that I think that the
response to this goes to the heart of the set of REST observations,
which is that one can usefully see HTTP as an application protocol,
and not just a transport protocol (others have made this point
earlier in this thread).
If you do this, then you will be pushed towards an architecture which
is robust because it goes with the grain of the web rather than
against it. Guy's UWS shows how one can approach a problem which
_appears_ to require an asynchronous messaging solution, and instead
design an architecture which addresses it using easily passed-around
names, which is better because it's simpler.
All the best,
Norman
--
------------------------------------------------------------------------
----
Norman Gray / http://nxg.me.uk
eurovotech.org / University of Leicester, UK
More information about the grid
mailing list