Open Stack

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]

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.

After looking over the docs[1] I am on the fence and I would like others to
weigh in.

[1] http://api.openstack.org/api-ref-identity.html


On Thu, Sep 26, 2013 at 10:49 AM, Michael Basnight <mbasnight at gmail.com>wrote:

> 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}
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130926/f81e9476/attachment.html>