The discussion happened quite a while ago with Rob. I was originally hoping we could have a single controller for both API and UI who's methods would handle returning both JSON and HTML which is really the rails way of doing it. But because of the requirement of the API and the need of the ServiceObject at the time
Rob asked that I send out what I did to the mailing list after reviewing his last pull request for Deployer which did not use the pattern in routes.rb in crowbar BC. It instead uses the singular over plural convention to separate UI vs API calls which did not seem like a great way to go. The current scheme in routes.rb does not allow for two pluralized controllers to have the same name, one for API and one for UI which from what I've read is the correct way to implement what we are trying to do. Using namespaces allows for two controllers with the same name with different locations in file system. Also what is in crowbar routes.rb still implies two controllers one for API and one for UI, the snippet you sent only covers JSON/API calls. -----Original Message----- From: Victor Lowther [mailto:victor.lowt...@gmail.com] Sent: Tuesday, March 05, 2013 6:13 PM To: Paterson, David Cc: crowbar Subject: Re: [Crowbar] Discussion: CB 2.0 routing pattern finalization On Tue, Mar 5, 2013 at 3:42 PM, <david_pater...@dell.com> wrote: > The routing pattern we use in CB2 needs to be finalized. Currently there are > a couple of different routing patterns in use which is going to lead to > problems down the road. > > Fact: We need to have two controllers per barclamp/managed object. One for > UI and another for API calls. There was an earlier discussion around using a > single controller for both UI and API, the output of this design discussion > is we need two. Where did this discussion happen? > Please let's assume there will be two moving forward and limit the scope of > this thread to the routing pattern. > > As a starting place we could use namespaces. The UI would use the root > namespace and api calls would fall under a :api namespace that includes a > version scope. > > Example routes for Network Barclamp > > resources :networks #UI routes for networks, URL > http:[host]:[port]/networks > > namespace :api > scope ':barclamp' do > scope ':version' do > resources :networks #Versioned API routes for networks , URL > http:[host]:[port]/api/network/v2/networks > resources :conduits #Versioned API routes for conduits, URL > http:[host]:[port]/api/network/v2/conduits > ... > end > end > end The scheme that Rob, Ward, Wayne and myself settled on looks like this (from the current routes.rb): # API routes (must be json and must prefix v2)() scope :defaults => {:format=> 'json'} do constraints(:id => /([a-zA-Z0-9\-\.\_]*)/, :version => /v[1-9]/ ) do # framework resources pattern (not barclamps specific) scope 'api' do scope 'status' do get "nodes(/:id)" => "nodes#status", :as=>:nodes_status get "deployments(/:id)" => "deployments#status", :as=>:deployments_status end scope ':version' do resources :nodes do resources :attribs resources :groups match 'transistion' # these should be limited to put, but being more lax for now match 'allocate' # these should be limited to put, but being more lax for now end resources :barclamps do resources :deployments end resources :deployments resources :snapshots resources :jigs #resources :users resources :attrib_types resources :attribs resources :role_types resources :roles resources :groups do member do get 'nodes' end end end # version end # api # Barclamp resource v2 API Pattern scope ':barclamp' do scope ':version' do match "template" => "barclamps#template" resources :deployments do member do put 'commit' put 'recall' end end resources :snapshots resources :roles do resources :attribs resources :nodes end resources :attribs end # version scope end # barclamp scope end # id constraints > The controllers would then be located in file system as follows: > [barclamp_root]/app/controllers/networks_controller.rb - UI Controller > [barclamp_root]/app/controllers/api/networks_controller.rb - API controller. > > There are other ways of doing, this is one idea. We need to settle on a > common scheme ASAP. > > Feedback please. > > > > > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
