> -----Original Message----- > From: Alex Huang [mailto:alex.hu...@citrix.com] > Sent: Thursday, April 04, 2013 7:19 AM > To: dev@cloudstack.apache.org > Subject: RE: [DISCUSS] RESTful API for CloudStack agents > > That's true. I don't believe the design itself is REST. It's http call but > to me it's > a much simpler transition path than coming up with a full REST for the agents. > I don't think we necessarily need full REST for the agents because they're not > really full services anyways. > > The http calls just allow for JSON format on top http instead of cloudstack's > proprietary protocol. That's a significant upgrade in of itself. > > With Donal's design here, someone can easily change AgentManager in > CloudStack to utilize this. I think it strikes a good compromise. We made a messy cloudstack API already, and it's hard to get rid of it, as a lot of clients((UI/marvin/jcloud, other cloudstack bindings)) are using this APIs already. We shouldn't make the mistake again, assuming that only AgentManager will use this agent APIs.
> > --Alex > > > -----Original Message----- > > From: Chip Childers [mailto:chip.child...@sungard.com] > > Sent: Thursday, April 4, 2013 6:39 AM > > To: dev@cloudstack.apache.org > > Cc: cloudstack-...@incubator.apache.org > > Subject: Re: [DISCUSS] RESTful API for CloudStack agents > > > > On Thu, Apr 04, 2013 at 11:44:33AM +0100, Donal Lafferty wrote: > > > Sorry for the delay in responding. > > > > > > The GET / POST limit to HTTP verbs simplifies exposing the agent > > > with HTML > > forms. Using these verbs the agent interface can be exposed via HTML > > forms should the developer want to use a browser for diagnostics, > > experimentation or testing. IIRC, HTML 5 expands set of acceptable > > methods, but sticking to HTML 4's GET/POST limit removes the HTML 5 limit. > > > > > > > Understood, but can't testing be done via a tool like curl just as > > easily? Being constrained by a presentation layer spec for an app to > > app integration seems odd. > > > > I'm not totally against your URI design, I just don't particularly > > love it. It's really just HTTP, so let's not call it REST at all if we go > > down that > path.
