On Tue, Apr 16, 2013 at 06:02:43PM +0530, Rohit Yadav wrote:
> Use what we have been using so far:
>
> API := :
>
> lowecase action :=
> CamelCaseSubjects :=
>
> So, based on such rule; the following makes sense:
> - configLdap
>
> About subjects, think what the API is trying to do. For examp
Use what we have been using so far:
API := :
lowecase action :=
CamelCaseSubjects :=
So, based on such rule; the following makes sense:
- configLdap
About subjects, think what the API is trying to do. For example;
addToLoadBalancerRule does not make sense, what are we adding to
LoadBalancerR
esday, April 16, 2013 4:34 PM
> To: dev@cloudstack.apache.org
> Subject: Re: API naming conventions
>
> Oh that's more than I intend to chew :)
>
> I only want the APIs to have some defined pattern - naming and semantics.
> This if from a integration perspective than fr
Oh that's more than I intend to chew :)
I only want the APIs to have some defined pattern - naming and
semantics. This if from a integration perspective than from the
perspective of a developer of cloudstack.
There is currently no documentation on what I should name my API and
how I choose b/w ov
+1 to this, but I guess this should be a subsection of a wiki called
"Adding a new api in Cloudstack - What all should I do ?"
Some of the subsections in it should be like (each with an example) :-
API naming conventions
Should the api be sync, async or asynccreate and what class should it
extend