[Pulp-list] API: Consider to only return JSON parseable results

Jay Dobies jason.dobies at redhat.com
Fri Dec 9 21:23:40 UTC 2011


On 12/07/2011 05:07 PM, Nick Coghlan wrote:
> 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.

Returning True for sync/publish is just a hack for now. You're right, 
those APIs are waiting on the async stuff to be in place. When that's 
done, the call will return the information on the created task and tell 
the caller how to track the operation.

I'm up in the air on what delete should return. The serialized objects 
that were deleted? A JSON report with some info on the delete such as 
how many items were deleted? I'm open to suggestions.



-- 
Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org




More information about the Pulp-list mailing list