UWS 1.1 alternative, WAIT

[Dave Morris]

Hi Paul,

On 2014-06-05 15:58, Paul Harrison wrote:
> 
> I am afraid that I am still not being convinced by the ?WAIT on more
> than a single specialised endpoint - it is in the spirit of keeping
> things as simple as possible, and not disturbing what is already
> established for a 1.1 update. ....

Yep, fair point. Just the 'blocking' endpoint then.

> I also think that avoiding redirects should not be an aim of any 
> changes

The reason for adding the blocking endpoint is to reduce the overhead of 
polling using using repeated GET requests to detect a status change. So 
the original aim of this was to avoid additional network traffic where 
possible.

The most common use case would probably be to create a job, start it 
running, and then poll the blocking endpoint to wait for a status 
change.

If the blocking endpoint returns with a redirect, the client knows that 
something has changed, but it doesn't know what. So the client has to 
make an additional GET request for the job details before it can work 
out what has changed.

If the blocking endpoint returned the full job details, the client would 
have all the information it needs and we would not need to make the 
second GET request.

This would halve the number of requests between client and server, 
significantly reducing the overhead needed to keep multiple clients 
updated.

> .... - redirects are in the original
> specification to make the interface a RESTy (with out being a zealot
> about it) and in most cases clients will automatically follow
> redirects. The original interface by having well defined responses for
> the various end-points with little or no conditionality means that

I appreciate you want to keep the redirect for consistency with the rest 
of the RESTy API.

Can we allow both, redirect and inline, by using a RESPONSE parameter 
which changes the behaviour from redirecting to the job details (in 
keeping with the rest of the API) to returning the job details in the 
response.

Using a separate blocking endpoint.

* Block until something 'interesting' happens, and then redirect to the 
job details.
   (default behaviour)

         GET /jobs/{jobid}/blocking
         GET /jobs/{jobid}/blocking?RESPONSE=REDIRECT

* Block until something 'interesting' happens, and then return the job 
details response.

         GET /jobs/{jobid}/blocking?RESPONSE=INLINE

* Block for up to to 10 seconds or something 'interesting' happens, and 
then redirect to the job details.

         GET /jobs/{jobid}/blocking?WAIT=10
         GET /jobs/{jobid}/blocking?WAIT=10&RESPONSE=REDIRECT

* Block for up to to 10 seconds or something 'interesting' happens, and 
then return the job details response.

         GET /jobs/{jobid}/blocking?WAIT=10&RESPONSE=INLINE

That way we maintain consistency with the rest of the API (default is to 
redirect) while allowing clients to request the inline response if they 
want it.


BTW - this is probably not an option, but technically, the blocking GET 
request could return both the 302 redirect header AND the job state in 
the body.

http://stackoverflow.com/a/8059718
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3

Clients who wanted the redirect could read the header, clients who 
wanted the job details could read the response body.


Cheers,
Dave

-------
Dave Morris
Software Developer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------