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
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
--
Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
