<div dir="ltr">I see PATCH used all over the keystone v3 API. Its not used at all in other older versions. I take that meaning that they did not want to add confusion or many changes in the current version of the API.[1]<div>
<div><br></div><div>Although since the Configuration is technically a new API being added to the core of Trove, should consider it to enhance the API now or keep it on par the way the rest of the API looks.</div></div><div>
<br></div><div>After looking over the docs[1] I am on the fence and I would like others to weigh in.</div><div><br></div><div>[1] <a href="http://api.openstack.org/api-ref-identity.html">http://api.openstack.org/api-ref-identity.html</a></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 26, 2013 at 10:49 AM, Michael Basnight <span dir="ltr"><<a href="mailto:mbasnight@gmail.com" target="_blank">mbasnight@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sep 25, 2013, at 7:16 PM, Craig Vyvial wrote:<br>
<br>
> 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.<br>
><br>
> <a href="https://blueprints.launchpad.net/trove/+spec/configuration-management" target="_blank">https://blueprints.launchpad.net/trove/+spec/configuration-management</a><br>
><br>
> This is an overview of the API calls for<br>
><br>
> POST /configurations - create config<br>
> GET  /configurations - list all configs<br>
> PUT  /configurations/{id} - update all the parameters<br>
><br>
> GET  /configurations/{id} - get details on a single config<br>
> GET  /configurations/{id}/{key} - get single parameter value that was set for the configuration<br>
><br>
> PUT  /configurations/{id}/{key} - update/insert a single parameter<br>
> DELETE  /configurations/{id}/{key} - delete a single parameter<br>
><br>
> GET  /configurations/{id}/instances - list of instances the config is assigned to<br>
> GET  /configurations/parameters - list of all configuration parameters<br>
><br>
> GET  /configurations/parameters/{key} - get details on a configuration parameter<br>
><br>
> There has been talk about using PATCH http action instead of PUT action for thie update of individual parameter(s).<br>
><br>
> PUT  /configurations/{id}/{key} - update/insert a single parameter<br>
> and/or<br>
> PATCH  /configurations/{id} - update/insert parameter(s)<br>
><br>
><br>
> 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?<br>
><br>
> If there are any concerns around this please let me know.<br>
<br>
</div></div>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.<br>

<br>
[1]  GET /configurations/{id}/{key}<br>
[2] PUT  /configurations/{id}/{key}<br>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>