[rest-practices] Async operations and statelessness

[Eoghan Glynn]

Unfortunately this expectation-setting approach is not going to fly, for
the reason explained here:

https://fedorahosted.org/pipermail/rhevm-api/2010-April/000146.html

/Eoghan

On Tue, 2010-04-27 at 17:58 +0100, Eoghan Glynn wrote:
> Folks,
> 
> I've been experimenting with various ways for a client to indicate that
> it wishes an action to be executed asynchronously, as opposed to
> blocking for completion. The idea would be to make this asynchrony
> optional so as to facilitate really simple clients which may not be set
> up to easily poll for completion.
> 
> Now I don't really like the idea of using an "?async=true" style of
> query parameter, as this would tend to bleed knowledge of the URI
> structure onto the client side.
> 
> In the case where the POST entity-body is non-empty (e.g. for migrate we
> might indicate a target host, or for reboot maybe a grace period or
> somesuch), then the async preference could simply be encoded in the task
> representation. But some actions are likely to have a empty body, and
> I'm leery about adding one just for the sake of the client's async
> preference. 
> 
> Another option would be to leverage the standard Expect header, with a
> custom expectation-extension in the style of the familiar "Expect:
> 100-Continue" usage.
> 
> So the client of a long-running action could set a header something with
> like "Expect: 202-Accepted", which the service would take as an explicit
> instruction to spin off an async task and return a 202. If the action
> could not be carried out in a non-blocking fashion for some reason, the
> service would bail with a 417 Expectation Failed.
> 
> Is there a whiff of sulphur around extending the semantics of an
> existing header in this way? Is it likely to cause trouble with
> intermediating proxies? There are some worrying comments in the RFC[1]
> to the effect that proxies must understand the expectation.
> 
> Cheers,
> Eoghan
> 
> 
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.20