On 12/08/2011 02:59 AM, Jay Dobies wrote:
100% agree. We're taking a much more REST-like approach with our APIs in
the future (truth be told, the current ones are a bit sloppy) where all
of the responses will be JSON parsable in the future.
There are a couple of v2 APIs that don't behave that way yet. As I
recall (and from looking at my current server interaction code), the
offenders are at least:
- deleting objects from collections
- the sync_repo action
(I'm not using publish_repo yet, but I assume it has the same problem as
sync_repo)
For sync_repo, I think it would be useful to return the new sync_history
entry generated for the sync operation.
When you get around to adding support for asynchronous explicit sync
requests, it may make sense to put that under a separate URL (e.g.
<repo_id>/actions/async/sync_repo) and leave the existing URL as a
potentially long-running operation. (Then again, it may make more sense
to be async by default and have the synchronous API use an alternate URL)
Cheers,
Nick.
--
Nick Coghlan
Red Hat Engineering Operations, Brisbane
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
