UWS as a REST protocol

[Guy Rixon]

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