UWS 1.1 alternative, WAIT

[Paul Harrison]

On 2014-06 -17, at 13:34, Dave Morris <dave.morris at metagrid.co.uk> wrote:

> On 2014-06-05 15:58, Paul Harrison wrote:
> 
>> 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.
> 
..
> 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.
> 
> 
I think that there is a reasonable argument for making the blocking endpoint /jobs/{jobid} with the ?WAIT parameter from your earlier suggestion in this thread - I cannot see a big downside to that at the moment (apart from making it a little more difficult for clients to detect lack of 1.1 capability) - it keep things simple and we don’t have to worry about redirects. I will to write this up in the Volute version of the spec if no-one has any objections, and then we should probably try some implementations.

> 
> 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.

I had wondered about doing this sort of thing in the past - it is an often overlooked part of the HTTP spec that the various “error” responses have bodies...

Paul.