On Sep 25, 2013, at 7:16 PM, Craig Vyvial wrote: > So we have a blueprint for this and there are a couple things to point out > that have changed since the inception of this BP. > > https://blueprints.launchpad.net/trove/+spec/configuration-management > > This is an overview of the API calls for > > POST /configurations - create config > GET /configurations - list all configs > PUT /configurations/{id} - update all the parameters > > GET /configurations/{id} - get details on a single config > GET /configurations/{id}/{key} - get single parameter value that was set for > the configuration > > PUT /configurations/{id}/{key} - update/insert a single parameter > DELETE /configurations/{id}/{key} - delete a single parameter > > GET /configurations/{id}/instances - list of instances the config is > assigned to > GET /configurations/parameters - list of all configuration parameters > > GET /configurations/parameters/{key} - get details on a configuration > parameter > > There has been talk about using PATCH http action instead of PUT action for > thie update of individual parameter(s). > > PUT /configurations/{id}/{key} - update/insert a single parameter > and/or > PATCH /configurations/{id} - update/insert parameter(s) > > > I am not sold on the idea of using PATCH unless its widely used in other > projects across Openstack. What does everyone think about this? > > If there are any concerns around this please let me know.
Im a fan of PATCH. Id rather have a different verb on the same resource than
creating a new sub-resource just to do the job of what PATCH defines. Im not
sure the [1] gives us any value, and i think its only around because of [2]. I
can see PATCH removing the need for [1], simplifying the API. And of course
removing the need for [2] since it _is_ the updating of a single kv pair. And i
know keystone and glance use PATCH for "updates" in their API as well.
[1] GET /configurations/{id}/{key}
[2] PUT /configurations/{id}/{key}
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
