[Pulp-list] schedule sub-collections

[Jeff Ortel]

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
>> 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>,
> }

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