Thanks for the interest in this topic. Here is a WIP FS:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/REST+API+Server+Arch
itecture. The real work has not been started yet. Feedback and suggestions
are welcome.
-min
On 2/25/13 8:36 AM, "John Burwell" wrote:
>+1 as well regarding shari
+1 as well regarding sharing earlier rather than later. Would it be possible
to publish the work in progress design to the wiki for wider community
visibility?
On Feb 24, 2013, at 9:10 PM, Rohit Yadav wrote:
> Hi Min, can you share your plans on this one so I can fix api
> discovery and cloud
On Mon, Feb 25, 2013 at 07:40:42AM +0530, Rohit Yadav wrote:
> Hi Min, can you share your plans on this one so I can fix api
> discovery and cloudmonkey. As CloudStack's release timelines would
> increase, I want to fix the api discovery in cloudmonkey such that
> it's maintainable and adapts to ch
Hi Min, can you share your plans on this one so I can fix api
discovery and cloudmonkey. As CloudStack's release timelines would
increase, I want to fix the api discovery in cloudmonkey such that
it's maintainable and adapts to changes withing api servers (the old
one, new rest one and cloud-engine
Currently I am working on redesigning a brand new REST compliant api
server. Will share the architecture design with the community when the
document is ready, then everybody can chip in to provide feedback on the
new proposal.
Thanks
-min
On 1/31/13 9:46 PM, "Ahmad Emneina" wrote:
>+1 on deprec
+1 on deprecation while bringing in the new. Does this avert the need for a
major version increment, or is this a big enough feature to warrant the big
five oh?
On Thu, Jan 31, 2013 at 9:36 PM, Prasanna Santhanam wrote:
> On Fri, Feb 01, 2013 at 01:35:58AM +0530, Rohit Yadav wrote:
> > On Thu,
On Fri, Feb 01, 2013 at 01:35:58AM +0530, Rohit Yadav wrote:
> On Thu, Jan 31, 2013 at 10:44 AM, John Burwell wrote:
> > All,
> >
> > I hate to be the pedantic REST guy, but I think there is a
> > different worth noting between PUT and POST. POST [1] should be
> > used for operations where the se
+1
--Alex
> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Thursday, January 31, 2013 10:45 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: cloudstack-us...@incubator.apache.org
> Subject: Re: [PROPOSAL] [DISCUSS] Deprecate CloudStack a
On Thu, Jan 31, 2013 at 10:44 AM, John Burwell wrote:
> All,
>
> I hate to be the pedantic REST guy, but I think there is a different worth
> noting between PUT and POST. POST [1] should be used for operations where
> the server will provide the identity of the resource where PUT [2] is
> inte
On Thu, Jan 31, 2013 at 5:28 AM, Prasanna Santhanam wrote:
> On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
>> I want to propose that we deprecated the current non-RESTful APIs and
>> api server over next few months, year, 2 years... (let's vote on the
>> timeline, what do you think
All,
I hate to be the pedantic REST guy, but I think there is a different worth
noting between PUT and POST. POST [1] should be used for operations where the
server will provide the identity of the resource where PUT [2] is intended for
operations where the client will provide the identity of
On Thu, Jan 31, 2013 at 12:44:36AM +0530, Rohit Yadav wrote:
> I want to propose that we deprecated the current non-RESTful APIs and
> api server over next few months, year, 2 years... (let's vote on the
> timeline, what do you think should be duration for maintaining old set
> of apis?). And, we w
I want to propose that we deprecated the current non-RESTful APIs and
api server over next few months, year, 2 years... (let's vote on the
timeline, what do you think should be duration for maintaining old set
of apis?). And, we work on a maintainable REST-ful api server using
JAX-RS (suggest any o
13 matches
Mail list logo
