incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <bhais...@apache.org>
Subject Re: [DISCUSS] Fwd: jclouds json parsing issue
Date Wed, 30 Jan 2013 21:17:26 GMT
On Wed, Jan 30, 2013 at 1:06 PM, Chip Childers
<chip.childers@sungard.com> wrote:
> On Wed, Jan 30, 2013 at 3:56 PM, Rohit Yadav <rohityadav89@gmail.com> wrote:
>> Did we change the response format to an envelop style?
>>
>> Cloudstack 3.x
>> deployvirtualmachineresponse.json : { "deployvirtualmachine" : {"id":1234,
>> "jobid":50006} }
>> Cloudstack 4.x
>> new json response : { "deployvirtualmachineresponse" :
>> {"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582-aa3e-90883c041ff0"},
>> "cloudstack-version": "4.1.0-SNAPSHOT" }
>
> It looks like there are two changes...  The name of the returned
> object (deployvirtualmachine vs deployvirtualmachineresponse), as well
> as the addition of the cloudstack-version field.

I've no idea about these changes and how and why they were made?
Comment or advise anyone?
I've been maintaining and working on the api layer about past two
months now and I feel this is the layer which the world talks to and
my aim is to make sure we keep minimal damages to projects who are
based on top of CloudStack if that requires us to deprecate it and
adopt something REST-ful or standardized. This is for future of
course, I still want feedback and info on the changes as Adrian
mentions.

>
> -chip
>
>> Forwarding comment from jclouds developer Adrian:
>>
>> ---------- Forwarded message ----------
>> From: Adrian Cole <notifications@github.com>
>> Date: Wed, Jan 30, 2013 at 12:25 PM
>> Subject: Re: [jclouds] cloudstack renamed deployvirtualmachineresponse in
>> version 4.1 (#1254)
>> To: jclouds/jclouds <jclouds@noreply.github.com>
>> Cc: Bhaisaab <rohityadav89@gmail.com>
>>
>>
>> @bhaisaab <https://github.com/bhaisaab> another note wrt the envelope style
>> used in cloudstack. If you are looking to support multiple version
>> detection, it would be much easier on us and others to use http mechanisms.
>> typically content mediation is done via headers, rather than wrapping
>> things in a thing that includes version and starts feeling like SOAP.
>> making a generator based on your style of doing versions is possible, but
>> it wouldn't be reusable code. If there's good reason to deviate from ReST
>> and other similar apis wrt Accept header and/or version headers, please
>> consider things that you are doing on your own, as making tools that only
>> work with the cloudstack way isn't enough gain to even use the metadata
>> service you describe. for example, there are specs like HAL
>> http://stateless.co/hal_specification.html that at least have a chance of
>> tooling support. Alternatively, you could go into the REST community and
>> pitch the way you do things and get others to adopt it. This could also
>> lead to tooling that isn't bespoke only to cloudstack.
>>
>> —
>> Reply to this email directly or view it on
>> GitHub<https://github.com/jclouds/jclouds/issues/1254#issuecomment-12910434>.

Mime
View raw message