UWS as a REST protocol

[Tony Linde]

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