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

Re: [Pulp-list] schedule sub-collections



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 redhat com
https://www.redhat.com/mailman/listinfo/pulp-list



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