[Pulp-list] REST Musings

[Nick Coghlan]

On 01/07/2012 01:36 AM, James Slagle wrote:
> As you already mentioned, I think we need to clearly document which API's
> are asynchronous in nature and those API's would have standard return codes
> that relate to the task resource that is returned.

 From a user point of view, having async APIs that consistently returned 
status codes related solely to whether or not the task was queued 
successfully would be just fine (on success, they should include a link 
to the relevant task status URL, but I believe Pulp already does that).

The only particularly painful case is if a particular API is "maybe 
sync, maybe async, depending on the input" - that gets annoying, since 
it can make it hard for me to correctly factor out the server 
interaction logic on the client side. Two separate APIs (i.e. one that 
is always synchronous, but may block for a long time before responding 
and one that is always asynchronous, even if the reply data is 
immediately available without needing to block) is much easier to handle.

Regards,
Nick.

-- 
Nick Coghlan
Red Hat Engineering Operations, Brisbane