On Jan 30, 2013, at 10:17 PM, Rohit Yadav <[email protected]> wrote:
> On Wed, Jan 30, 2013 at 1:06 PM, Chip Childers > <[email protected]> wrote: >> On Wed, Jan 30, 2013 at 3:56 PM, Rohit Yadav <[email protected]> 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. Rohit, I think we are still trying to figure out if this is a real issue, if something got changed or not. I will see Charles on Friday and we will go through his workflow, I will check the version numbers etc and try to figure out what the real issue is. Your work on API refactoring, while I did not follow all of it :), was terrific. Long term there should probably be a move to pure REST. -Sebastien > >> >> -chip >> >>> Forwarding comment from jclouds developer Adrian: >>> >>> ---------- Forwarded message ---------- >>> From: Adrian Cole <[email protected]> >>> Date: Wed, Jan 30, 2013 at 12:25 PM >>> Subject: Re: [jclouds] cloudstack renamed deployvirtualmachineresponse in >>> version 4.1 (#1254) >>> To: jclouds/jclouds <[email protected]> >>> Cc: Bhaisaab <[email protected]> >>> >>> >>> @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>.
