[openstack-dev] Cloudpipe extension response format

Dolph Mathews dolph.mathews at gmail.com
Wed Sep 26 13:39:00 UTC 2012


Keystone's xml serializer addresses this just as you describe. Given the
original JSON, it would produce:

    <cloudpipes>
        <cloudpipe project_id="**b7f6d49c12714e96a05fada4aba4ea**d6"
...etc... />
    </cloudpipes>

By recognizing that A) "cloudpipes" *looks* plural, and B) it refers to a
list of stuff, so assume that "cloudpipe" is the child element by
convention (after checking for hardcoded exceptions):


https://github.com/openstack/keystone/blob/master/keystone/common/serializer.py#L170

-Dolph


On Wed, Sep 26, 2012 at 8:26 AM, Sean Dague <sdague at linux.vnet.ibm.com>wrote:

> On 09/25/2012 05:00 PM, Vishvananda Ishaya wrote:
>
>> Hey Mauro,
>>
>> I don't think it is acceptable to change the json representation. If we
>> need a different representation to make xml work, then we will just have to
>> translate back and forth. An alternative (and probably better) option would
>> be to change the json representation but have it also accept and convert
>> the old json representation. We really can't break an interface that people
>> are already using.
>>
>> And yes, changing the test to actually do a real xml request would be
>> preferrable.
>>
>> Vish
>>
>> On Sep 25, 2012, at 12:54 PM, Mauro Rodrigues <maurosr at linux.vnet.ibm.com>
>> wrote:
>>
>>  Hi guys, how are you doing?
>>>
>>> Well, I'm working on API samples to Cloudpipe extension[1]. To JSON it
>>> works just fine, although when using XML it works partially. what do I mean?
>>> For JSON, when creating a cloudpipe, the response comes with the follow:
>>> { "instance_id": "8250f384-ee8a-43b7-9eb2-**453e5bbdd019" }
>>> So using XML I was waiting the same information, looking like this:
>>>
>>> <instance_id>ff1f7847-2bd3-**4385-9bbe-d273cea01ba4</**instance_id>
>>>
>>> Instead I got just a empty string.
>>>
>>> A similar problem occurs when trying to list cloudpipes, to Json we had
>>> the follow response:
>>> {
>>>     "cloudpipes": [
>>>         {
>>>             "project_id": "**b7f6d49c12714e96a05fada4aba4ea**d6",
>>>             "internal_ip": "10.0.0.2",
>>>             "public_ip": "192.168.1.100",
>>>             "public_port": 8000,
>>>             "state": "running",
>>>             "instance_id": "8250f384-ee8a-43b7-9eb2-**453e5bbdd019",
>>>             "created_at": "1981-10-20T00:00:00Z"
>>>         },
>>>     ]
>>> }
>>>
>>> For XML only:
>>> <cloudpipes>
>>> <cloudpipe/>
>>> </cloudpipes>
>>>
>>
> Does this just mean the XML serializer doesn't do anonymous dictionaries?
> Seems like in those cases we could put a work around in the XML serializer
> to handle this instead of changing the JSON.
>
> Also something to flag for future API calls that anonymous dictionaries
> should be avoided because of this kind of challenge. Probably worth adding
> a comment and bug around it and linking to this blueprint -
> https://blueprints.launchpad.**net/nova/+spec/v2-api-**inconsistencies<https://blueprints.launchpad.net/nova/+spec/v2-api-inconsistencies>
> .
>
>         -Sean
>
> --
> Sean Dague
> IBM Linux Technology Center
> email: sdague at linux.vnet.ibm.com
> alt-email: sldague at us.ibm.com
>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/20120926/7611c695/attachment.html>


More information about the OpenStack-dev mailing list