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

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



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


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