cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject [DISCUSS] Fwd: jclouds json parsing issue
Date Wed, 30 Jan 2013 20:56:50 GMT
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" :
"cloudstack-version": "4.1.0-SNAPSHOT" }
Forwarding comment from jclouds developer Adrian:

---------- Forwarded message ----------
From: Adrian Cole <>
Date: Wed, Jan 30, 2013 at 12:25 PM
Subject: Re: [jclouds] cloudstack renamed deployvirtualmachineresponse in
version 4.1 (#1254)
To: jclouds/jclouds <>
Cc: Bhaisaab <>

@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 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message