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

Re: [Pulp-list] schedule sub-collections

On 09/11/2012 07:39 AM, Jay Dobies wrote:
On 09/11/2012 01:13 AM, Jason Connor wrote:
Been doing a little thinking, my current model for schedule
sub-collections kinda sucks.

It's as follows (for the schedule REST APIs defined so far):

/v2/repositories/<repo id>/importers/<importer id>/sync_schedules/
/v2/repositories/<repo id>/distributors/<distributor
/v2/consumers/<consumer id>/unit_install_schedules/

I think the repo importers and distributors sub-collections kinda
tripped me up. I think the following is a better (more RESTful?)
implementation, and I'm looking for feedback (thumbs up/thumbs down
kinda thing)

/v2/repositories/<repo id>/importers/<importer id>/schedules/sync/
/v2/repositories/<repo id>/distributors/<distributor

These two make sense to me from a REST point of view. There's a lot of
information here:

* The schedule belongs to a specific plugin instance on the repo
* We have room for more operations than simply sync and publish
* Retrieval fits the model: GET on the above shows all schedules,
tacking on a schedule ID addresses that particular schedule.

It's long and complicated, but it's REST-y, and this isn't the first
time I've mentioned that I think the majority of arguments in favor of
REST don't typically think outside of simple theoreticals.

/v2/consumers/<consumer id>/schedules/unit_install/
/v2/consumers/<consumer id>/schedules/unit_update/
/v2/consumers/<consumer id>/schedules/unit_uninstall/

This one feels odd because of all of the unit_*. It also feels like if
we have this many examples namespaces to unit_*, I wonder if there's
something off. Thing is, I'm not totally sure what it is.

(largely thinking out loud here)

The more I think about it, all of these are actions (sync, publish,
unit_*). I can see a REST argument that they aren't sub-resources but
merely an attribute on the schedule, namely the type of action that's

This is especially true in the unit_* cases. What you're doing with the
units is data in the same sense that the unit list is itself, which
isn't part of the URL. I like the idea of:

/v2/consumers/<consumer id>/schedules/unit_install/
/v2/consumers/<consumer id>/schedules/units/

With a body of:

   'operation' : 'install',
   'units' : ['okaara'],
   'schedule' : <schedule stuffs>,

I agree, part. The unit_* seems odd. But having the action in body instead of the URL seems ... un-RESTful. I prefer something along the lines of Nick's suggestion:

/v2/consumers/<consumer id>/schedules/content/install/
/v2/consumers/<consumer id>/schedules/content/update/
/v2/consumers/<consumer id>/schedules/content/uninstall/

This approach is also consistent with existing non-scheduled content installs:

/v2/consumers/<consumer id>/actions/content/install/
/v2/consumers/<consumer id>/actions/content/update/
/v2/consumers/<consumer id>/actions/content/uninstall/

Jason L Connor
linear on freenode #pulp
RHCE: 805010912355231
GPG Fingerprint: 2048R/CC4ED7C1

Pulp-list mailing list
Pulp-list redhat com

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