Hi Arvind, what you suggest is a little more change than I think we need right now; in particular, there's no reason for us to switch to Rails - Sinatra has and is serving us well.
VersionCake is a terrible idea for a RESTful API - and the sort of version negotiation that he suggests through headers is completely the wrong way to go. See [1] for more info. As for auth, Deltacloud doesn't handle authorization at all, by design. It simply passes credentials through to the backend cloud. David [1] http://www.watzmann.net/blog/2012/08/rest-api-evolution.html On Tue, 2013-04-09 at 21:11 +0530, Arvind Creatrix IT Soft wrote: > Hi > > With ref to the discussion- I was already planning to work on creating an API > over the core Delta Cloud code as I need it in a number of my projects. > > I suggest the following means to do this, in as painless a manner as > possible-- > > (1) Use Rails and RABL--> https://github.com/nesquena/rabl to generate the API > (2) Use the VersionCake gem for versioning( > https://github.com/bwillis/versioncake) > (3) Controllers are set up in an hierarchy where you have one BaseController > which contains this authentication logic (as a before_filter) and then the > other controllers inherit from that. If you have any other helpers, they > would go in this controller too. > (4) For authorization, use CanCan.(https://github.com/ryanb/cancan) It's > README and Wiki are great sources of information on how to use it. > > Finally, here is some helpful text from the RABL docs--> > > Once you have installed RABL (explained above), you can construct a RABL view > template and then render the template from your Sinatra, Padrino or Rails > applications from the controller (or route) very easily. Using Padrino as an > example, assuming you have aPost model filled with blog posts, you can render > an API representation (both JSON and XML) by creating a route: > > # app/app.rb > get "/posts", :provides => [:json, :xml] do > @user = current_user > @posts = Post.order("id DESC") > render "posts/index" > end > Then we can create the following RABL template to express the API output of > @posts: > > # app/views/posts/index.rabl > collection @posts > attributes :id, :title, :subject > child(:user) { attributes :full_name } > node(:read) { |post| post.read_by?(@user) } > Which would output the following JSON or XML when visiting > http://localhost:3000/posts.json > > [{ "post" : > { > "id" : 5, title: "...", subject: "...", > "user" : { full_name : "..." }, > "read" : true > } > }] > This is an easy way to create a API library that has its own versioning- and > at the same time it basically just uses the core code in the Delta Cloud > library itself. > > Yours sincerely, > Arvind, > Creatrix IT Soft. > -----Original Message----- > From: Jozef Zigmund > Sent: Tuesday, April 9, 2013 7:28 PM > To: dev@deltacloud.apache.org > Cc: Martin Povolny ; aeolus-devel > Subject: Re: deltacloud as a lib and broker > > On Mon, 2013-04-08 at 16:45 -0700, David Lutterkort wrote: > > On Mon, 2013-04-08 at 14:44 +0200, Jan Provaznik wrote: > > > > There are some other downsides to using DC in process (as a library): it > > > > also significantly changes where DC can go architecturally. So far, the > > > > classic DC API has worked very hard to be stateless - CIMI isn't, and it > > > > wouldn't be unreasonable to introduce state into the classic DC API. > > > > That would be much more awkward if DC becomes a library. > > > > > > > > > > I'm not familiar with DC plans (which sound really interesting) but even > > > with stateful DC the lib could make sense: > > > 1) the DC lib - can be used by anyone who doesn't need any stateful > > > feature > > > 2) DC/CIMI stateful service - built *on top* of the lib, wraps the lib > > > with REST API, adds stateful features > > > > I think this is the right way to slice things up: make the DC service(s) > > wrappers around the DC library. The library essentially deals with > > adapting the internal driver API to something stable, and probably will > > make the API look a little more Rubyish. For example, right now code to > > start and stop an instance would look something like > > > > dc = Deltacloud::new(some_backend, some_provider, credentials) > > inst = dc.create_instance(...) > > unless starts_automatically(dc) # needs to look at > > instance_states > > wait_for_state(dc, inst, "STOPPED") > > dc.start_instance(credentials, inst.id) > > end > > wait_for_state(dc, inst, "STARTED") > > .. do stuff with your running instance .. > > dc.stop_instance(dc, inst) > > > > As you can see, the above isn't very Rubyish; it would be nicer to write > > > > dc = Deltacloud::new(some_backend, some_provider, credentials) > > inst = dc.create_instance(...) > > if inst.initial_state == 'STOPPED' > > inst.poll_for { |inst| inst.stopped? } > > inst.start > > end > > inst.poll_for { |inst| inst.started? } > > .. do stuff with your running instance .. > > inst.stop > > > > What I am mostly after is a feel for who's going to do the following > > around a DC library: > > > > * Come up with a library API that is safe to use - that includes > > keeping the API stable and making sure we only expose reasonable > > parts of the driver API. We don't want an automatic "It's in the > > drivers, therefore it's part of the API" > > * Write enough tests to convince us that the library API still > > works > > * Document that API > > > > Ok .. who's raising their hand ? ;) > > > > I'm in to help with it. > > > David > > > > >
