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, UKReceived on 2007-03-14Z11:16:45