Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of shivatejau@gmail.com designates
 209.85.215.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANLSSBXA08QJ0P=JPZ_8JSdvtvbBKKuBG3mKUo-JbS7_kx2-zg@mail.gmail.com>
References: 
 <CAJrLSbaqa08uHw_xETt7Q59Nex=ThQzvqEJyoXK8Q-OwN04Suw@mail.gmail.com>
	<CANLSSBXA08QJ0P=JPZ_8JSdvtvbBKKuBG3mKUo-JbS7_kx2-zg@mail.gmail.com>
Date: Mon, 29 Apr 2013 01:53:56 +0530
Message-ID: 
 <CAJrLSbbNQYvPvk+JWp_tdGB7vP1g-CRrS+Fzw-MUC2VZ7-8_Pw@mail.gmail.com>
Subject: Re: [GSoC] Introduction and Project Discussion
From: Shiva Teja <shivatejau@gmail.com>
To: dev@cloudstack.apache.org
Content-Type: multipart/alternative; boundary=047d7b343f022a06a204db718cb8

--047d7b343f022a06a204db718cb8
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Rohit,

I think you made my work a lot easier :) I can use code from cloudmonkey to
generate API cache and then build the code for the wrapper using it.

I might need some information on this. How would a RESTful CloudStack API
look like ? If I get these basic rules, I am guessing it shouldn't be tough
to generate the wrapper.

Here's a very basic idea. I am using the same terminology used in
cloudmonkey. In "listUsers", users is subject and list is the verb.
In most of the cases the URL for an API command can be something like
"baseurl/subject/verb" with an appropriately chosen HTTP method based on
the verb. For some "verbs" like list, get, update, delete, add, it doesn't
make sense to have them in the URL and using the appropriate HTTP method
would mean the same. So I'll have to write the rules for each verb. These
rules might contain method to be used for the verb, should the verb be in
the URL or not...etc. And use these rules to generate the wrapper.

I am trying to decide these rules, so that they don't deviate from the
point of being a RESTful API. Will get back with final implementation
details before I finish my application for GSoC.

Regard,
Shiva Teja(irc: teja)


On Sat, Apr 27, 2013 at 10:14 PM, Rohit Yadav <bhaisaab@apache.org> wrote:

> Hi Shiva,
>
> On Sat, Apr 27, 2013 at 1:29 AM, Shiva Teja <shivatejau@gmail.com> wrote:
>
> > Hi all,
> >
> > I am Shiva Teja, an undergrad student from IIT Mandi, India. I will be
> > participating in GSoC this year. I'd like to work on the new CloudStack
> UI
> > with bootstrap project[1]. I've been experimenting with API for the pas=
t
> > few days. After reading a couple of blog posts by Sebastien, his recent
> > hack on this[2] and a recent discussion[3] on the mailing list about
> making
> > CloudStack API RESTfull, here are the things I plan to do.
> >
>
> Have you started working on your plan or just proposing? Hope you have a
> setup and tried CloudStack on DevCloud. For starters I suggest you to
> download, build and deploy CloudStack, play around APIs, cloudmonkey (a
> CLI) and the API Discovery service because both of your idea proposals ar=
e
> around APIs.
>
> 1. A more "human", RESTfull wrapper API on top of CloudStack API using
> > Flask python framework. Something like "GET /users" will directly
> > correspond to "listUsers" API command. "DELETE /user/<id>" will
> correspond
> > to the respective "deleteUser" API call.
> >
>
> It's tricky, first you should get a full list of entities. It's a lot of
> hard work if you do it manually but you can do smartly if you use Api
> Discovery. There are more than 300+ APIs in CloudStack, now groupped as p=
er
> entities (see a package like org.apache.cloudstack.api.<entitiy>.<api cmd
> class>).
>
> So, first you need to classify the entities, get it checked (like write
> tests) and then define these operations. Few of us are inclined towards
> rewriting an API server that is RESTful and not query based. The challeng=
e
> there is to reuse present cmd classes, one way is to use reflections and
> another round of api annotations refactoring. Easiest way would be to jus=
t
> fix/add/reuse Api Discovery, or write something use metaprogamming that
> auto generates your wrapper.
>
> I'm floating these ideas so you can think about it and come up with a
> strategy that creates maintainable, extendable code which would require
> less time to implement it.
>
> 2. A complete UI designed using Twitter Bootstrap and Backbone.js.
> > Obviously this will use the API that I'll be making.
> >
>
> +1 This is a fantastic idea, a better, faster, modular UI that is
> responsive is much appreciated and we will have an alternative to the
> default one.
>
> Avoid sending direct emails to anyone and feel free to reach out to the d=
ev
> ML, email like a boss=99.
>
> Happy hacking!
>
> Cheers.
>
> (An app made using Bootstrap and Backbone.js:
> > http://coenraets.org/directory/ )
> >
> > Any suggestions/comments ?
> >
> > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-1778
> > [2] https://github.com/runseb/cloudstack-flask
> > [3]
> >
> >
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201304.mbox/%3C20=
130424083847.GA11354%40cloud-2.local%3E
> >
> > Thanks,
> > Shiva Teja.
> >
>

--047d7b343f022a06a204db718cb8--