[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] REST Musings



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]