I'm all for a Flask wrapper for the CloudStack API. Would make custom UIs super easy(Proud Flask user here).
>-----Original Message----- >From: Shiva Teja [mailto:shivate...@gmail.com] >Sent: Sunday, April 28, 2013 11:24 PM >To: dev@cloudstack.apache.org >Subject: Re: [GSoC] Introduction and Project Discussion > >This probably needs of lot of discussion. For now, I'll stick to basics and >concentrate more on the UI. Thanks for the help. > >Regards, >Shiva Teja. > > >On Mon, Apr 29, 2013 at 10:45 AM, Rohit Yadav <bhais...@apache.org> >wrote: > >> On Mon, Apr 29, 2013 at 1:53 AM, Shiva Teja <shivate...@gmail.com> >wrote: >> >> > 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 ? >> >> >> This is a hard issue because the challenge is not just to implement >> something, but something that will be maintainable. Your APIs are your >> interface or contract to the outside world so once you give away your >> spec to the outside world, you've the burden to keep backward >> compatibility and not mess up when you do any kind of refactoring. >> >> Some general rules I see are; all entities are nouns, the verbs are >> not part of the url but how you call them; so list/read would be GET, >> create would be POST, update would be PUT, remove/del would be >> DELETE... that said you can create your own X- headers to mean >> something. People have written books, gave talk on how to write good >RESTful APIs. >> >> >> > If I get these basic rules, I am guessing it shouldn't be tough to >> > generate the wrapper. >> > >> >> The implementation won't be tough, but getting it right would be. >> Right now I'm just splitting the apiname at the camelCase's hump in >> cloudmonkey, so camel becomes a command and Case becomes the entity. >> >> >> > >> > 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. >> > >> >> It's not straight forward, for example create/add/generate are few >> words in apis which would be GET Apis in restful terms. One way would >> be to manually sort/group the apis, other would be to annotate each >> api with an entity name, RESTful type {one of GET, POST, PUT etc.} and >> parent (For example, /zone/pod/cluster makes sense?). >> >> >> > 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. >> > >> >> Lastly, talk to Sebastien or someone who would is participating in >> GSoC as a mentor because it's important to identify who would mentor >> you if they would, best of luck. >> >> Cheers. >> I'm skipping applying to being a GSoC mentor this year, pissed off >> from GSoC admins this year. FOSS is just going to dogs; fck they did >> not include one project that has no real company to back its >> development and really needs help; VideoLAN/VLC. >> >> >> >> > Regard, >> > Shiva Teja(irc: teja) >> > >> > >> > On Sat, Apr 27, 2013 at 10:14 PM, Rohit Yadav <bhais...@apache.org> >> wrote: >> > >> > > Hi Shiva, >> > > >> > > On Sat, Apr 27, 2013 at 1:29 AM, Shiva Teja <shivate...@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 >> > past >> > > > 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 >> > are >> > > 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 >> > per >> > > 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 >> > challenge >> > > 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 >> > just >> > > 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 >> > dev >> > > ML, email like a bossT. >> > > >> > > 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/%3 >> C20130424083847.GA11354%40cloud-2.local%3E >> > > > >> > > > Thanks, >> > > > Shiva Teja. >> > > > >> > > >> > >>
