UWS as a REST protocol

[Guy Rixon]

Thanks, Tony.

I note that GET etc. _should_ be idempotent but one can code up web apps where
there aren't.

On Tue, 27 Feb 2007, Tony Linde wrote:

> For anyone else baffled:
>
> Idempotent
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2)
> 9.1.2 Idempotent Methods
> Methods can also have the property of "idempotence" in that (aside from
> error or expiration issues) the side-effects of N > 0 identical requests is
> the same as for a single request. The methods GET, HEAD, PUT and DELETE
> share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have
> side effects, and so are inherently idempotent.
>
> However, it is possible that a sequence of several requests is non-
> idempotent, even if all of the methods executed in that sequence are
> idempotent. (A sequence is idempotent if a single execution of the entire
> sequence always yields a result that is not changed by a reexecution of all,
> or part, of that sequence.) For example, a sequence is non-idempotent if its
> result depends on a value that is later modified in the same sequence.
>
> A sequence that never has side effects is idempotent, by definition
> (provided that no concurrent operations are being executed on the same set
> of resources).
>
>
> > -----Original Message-----
> > From: owner-grid at eso.org [mailto:owner-grid at eso.org] On
> > Behalf Of Guy Rixon
> > Sent: 27 February 2007 15:00
> > To: Roy Williams
> > Cc: John Taylor; Matthew Graham; grid at ivoa.net
> > Subject: Re: UWS as a REST protocol
> >
> > On Tue, 27 Feb 2007, Roy Williams wrote:
> >
> > > as soon as you click they come alive. VOSpace objects and
> > dynamically
> > > computed image cutouts and other sorts of service calls. SOAP is a
> > > necessary evil when requests and responses get complicated
> > and we are
> > > forced to the complicated protocol.
> > >
> > > But then there is the religious part. Why can't we have
> > verbs? Like this:
> > > http://blabla.edu?service=cutout&POS=301,22&recipe=bombayduck
> >
> > You _can_ have this, provided that it's an idempotent call.
> > If the service
> > always gives you the same thing for the same URL then you can
> > use all the
> > query parameters you want. It _might_ be clearer if it were
> >
> >   http://blabla.edu/cutout/bombayduck?POS=201,22
> >
> > (presuming that there are other operations at blahblah.edu
> > and other recipies
> > on the cutout) but either forms work just as well.
> >
> > If all your services are stateless HTTP-get calls then they
> > are implicitly
> > RESTful. It's when you _create_ things on the server in one
> > call and acces
> > them in another that REST has specific ways of doing it.
> >
> >
> > > The clergy of RESTfulness want this to be written some other way (is
> > > that right?)
> > > http://blabla.edu/cutout/301/22/bombayduck
> >
> > If the lists of services and recipies are finite, then you
> > might make a tree
> > of resources for each combination. You couldn't merge all the
> > position options
> > into this tree because the coordinates are continously
> > variable, not discrete.
> >
> > HOWEVER, it _doesn't matter_ when the URL is getting a
> > resource and not
> > changing server state. The tree is prefered by some because
> > it fits in with
> > what you use in a _stateful_ service, one where you create ephemeral
> > resources.
> >
> > > What is the theological basis of RESTfulness?
> >
> > The S is for state: it's about stateful services (e.g. HTTP
> > call A starts a
> > job and call B gets the results) a.k.a synchronous services.
> > if your service
> > is stateless then none of the theology really matters.
> >
> > REST works because operations that change server state make
> > available to the
> > client a new resource with an explict URL. Post a request to
> > start a job; get
> > back a URL for a job resource. That's the bit that doesn't
> > happen with SOAP.
> >
> > > Why is it better than VERBishness?
> >
> > It is no more functional than VERBishness for most stateless
> > services. There
> > may be an edge case in that services can be self describing. Consider
> >
> >   http://blahblah.edu/services/cutout/bombayduck
> >   http://blahblah.edu/services/cutout/chickenmadras
> >   http://blahblah.edu/services/mosaic/roastbeef
> >
> > then it could be arranged that the services resource is a
> > list of services
> > and the cutout and mosaic resources are lists of recipies. A
> > client could
> > then navigate this tree to see what the particular service-group could
> > offer. (And yes, you could probably give these lists of
> > options in response to
> > cunningly-chosen verbs; but with the tree it's obvious how to
> > get them.)
> >
> > > Why is is bad for a URL to have side-effects?
> >
> > It isn't bad; but you shouldn't mix idempotent resources with
> > the ones with
> > side effects. The side-effective ones need to be POST only to
> > distinguish
> > them. In REST, the side effect alway creates some new resource.
> >
> > Further, if you're using side-effective URLs from a
> > web-browser you need a way
> > to navigate the side that doesn't involve backing-up over
> > them or having to
> > refresh them to see the results. (You get this in Expedia: if
> > you go back
> > while choosing a flight it all goes pear-shaped.) Therefore,
> > one of the
> > principles of REST is that the response to a side-effective
> > request takes you
> > to some other resource that can be got, not posted.  I find
> > that the best way
> > to do this with browsers is to redirect to that idempotent resource.
> >
> > > Why can't VERBish things be cached just as well?
> >
> > They can if they are idempotent.
> >
> > Guy Rixon 				        gtr at ast.cam.ac.uk
> > Institute of Astronomy   	                Tel: +44-1223-337542
> > Madingley Road, Cambridge, UK, CB3 0HA		Fax:
> > +44-1223-337523
> >
>
> http://www.Taglocity.com Tags: IVOA, grid
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523