Re: [Pulp-list] REST Musings

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.