[Pulp-list] REST Musings
Nick Coghlan
ncoghlan at redhat.com
Mon Jan 9 01:25:54 UTC 2012
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
More information about the Pulp-list
mailing list