[openstack-dev] Cloudpipe extension response format

Sean Dague sdague at linux.vnet.ibm.com
Wed Sep 26 13:26:03 UTC 2012


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": "b7f6d49c12714e96a05fada4aba4ead6",
>>             "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.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com




More information about the OpenStack-dev mailing list