[Pulp-list] schedule sub-collections

[Jay Dobies]

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 id>/publish_schedules/
> /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 id>/schedules/publish/

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 
executed.

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/
or
/v2/consumers/<consumer id>/schedules/units/

With a body of:

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


> Jason L Connor
> linear on freenode #pulp
> http://pulpproject.org/
> RHCE: 805010912355231
> GPG Fingerprint: 2048R/CC4ED7C1
>
>
>
>
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list
>


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