Open Stack

On Wed, Feb 26, 2014 at 02:17:53PM -0500, Jay Dobies wrote:
> This is a new concept to me in JSON, I've never heard of a wrapper 
> element like that being called a namespace.

I named it "namespace" in my email. It is not any kind of formal or
standard naming. "Wrapper element" is better name for this... wrapper
element :-)
> 
> My first impression is that is looks like cruft. If there's nothing else 
> at the root of the JSON document besides the namespace, all it means is 
> that every time I go to access relevant data I have an extra layer of 
> indirection. Something like:
> 
> volume_wrapper = get_volume(url)
> volume = volume_wrapper['volume']
> 
> or
> 
> volume = get_volume(url)
> name = volume['volume']['name']

I agree with you w/r/t to indirection when accessing data but I like the
idea that when I look at json repsonse I see what type of resource it
is. That wrapper element describes it. And I do not need to know what
request (url, service, GET or POST...) triggered that output.

> 
> If we ever forsee an aggregate API, I can see some value in it. For 
> instance, a single call that aggregates a volume with some relevant 
> metrics from ceilometer. In that case, I could see leaving both distinct 
> data sets separate at the root with some form of namespace rather than 
> attempting to merge the data.
> 
> Even in that case, I think it'd be up to the aggregate API to introduce 
> that.
> 
> Looking at api.openstack.org, there doesn't appear to be any high level 
> resource get that would aggregate the different subcollections.
> 
> For instance, {tenant_id}/volumes stuffs everything inside of an element 
> called "volumes". {tenant_id}/types stuffs everything inside of an 
> element called volume_types. If a call to {tenant_id} aggregated both of 
> those, then I can see leaving the namespace in on the single ID look ups 
> for consistency (even if it's redundant). However, the API doesn't 
> appear to support that, so just looking at the examples given it looks 
> like an added layer of depth that carries no extra information and makes 
> using the returned result a bit awkward IMO.
> 

I did not think about aggregate APIs before... interesting idea...
> 
> On 02/26/2014 01:38 PM, Petr Blaho wrote:
> > Hi,
> >
> > I am wondering what is the OpenStack way of returning json from
> > apiclient.
> >
> > I have got 2 different JSON response examples from http://api.openstack.org/:
> >
> > json output with namespace:
> > {
> >    "volume":
> >    {
> >      "status":"available",
> >      "availability_zone":"nova",
> >      "id":"5aa119a8-d25b-45a7-8d1b-88e127885635",
> >      "name":"vol-002",
> >      "volume_type":"None",
> >      "metadata":{
> >        "contents":"not junk"
> >      }
> >    }
> > }
> > (example for GET 'v2/{tenant_id}/volumes/{volume_id}' of Block Storage API v2.0 taken from
> > http://api.openstack.org/api-ref-blockstorage.html [most values ommited])
> >
> > json output without namespace:
> > {
> >    "alarm_actions": [
> >        "http://site:8000/alarm"
> >      ],
> >      "alarm_id": null,
> >      "combination_rule": null,
> >      "description": "An alarm",
> >      "enabled": true,
> >      "type": "threshold",
> >      "user_id": "c96c887c216949acbdfbd8b494863567"
> > }
> > (example for GET 'v2/alarms/{alarm_id}' of Telemetry API v2.0 taken from
> > http://api.openstack.org/api-ref-telemetry.html [most values ommited])
> >
> > Tuskar API now uses "without namespace" variant.
> >
> > By looking at API docs at http://api.openstack.org/ I can say that
> > projects use both ways, altought what I would describe as "nicer API"
> > uses namespaced variant.
> >
> > So, returning to my question, does OpenStack have some rules what
> > format of JSON (namespaced or not) should APIs return?
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Petr Blaho, pblaho at redhat.com
Software Engineer