RESTful Web services and DAL

[Doug Tody]

This is my view as well; the full REST model does not seem to work very
well for a service with complex operations involving many parameters.
Plus, what you ended up with would replace what is now a simple atomic
operation with multiple HTTP operations which require state to be
maintained on the server until the operation finally can be fired off.
Plus simple Web semantics such as issuing the GET in a browser or with
wget/curl, caching, etc., would no longer work.

The current DAL model is simple, and uses synchronous, idempotent GETs
for the most basic operations.  All the asynchrous stuff has been
factored off into the "stageData" operation and associated plumbing
(which is still TBD).  Clearly, stageData should be a POST, as should
any control operations for aborting the operation, or anything else which
changes state.  Client monitoring of a long-running stageData operation
can probably be done with GETs.  The GETs can be both of the simple
polling type, or a streaming GET could be used to provide asynchronous
messaging, as described in earlier messages.

	- Doug


On Thu, 15 Mar 2007, Paul Harrison wrote:

>
> On 14.03.2007, at 11:16, Norman Gray wrote:
>
> >
> >> 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.
>
> I too think that there is definitely a role for URLs with parameters
> in a REST-style interface - in the S*AP services, there is no strong
> natural ordering of parameters, and some of them are optional, so
> mapping them to a strict path style just does not work, as you cannot
> reliably associate them with a level in the path hierarchy
>
> unless you start do to things like...
>
> http://server.com/siap/ra=30/dec=20/
>
> but even then
>
> http://server.com/siap/dec=20/ra=30/
>
> obviously (to a human reader) points at the same "resource" even
> though they are different uris - which is not usefully RESTful
> behaviour.
>
> It seems to me that trying to be blindly 100% compliant with any
> methodology nearly always produces worse results than being a little
> flexible - in fact the skill of a good programmer is knowing when to
> break the rules.
>
> Paul Harrison
> ESO Garching
> www.eso.org
>