RESTful Web services and DAL

[Norman Gray]

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