Merge / split controller for UI and API?

Petr Blaho pblaho at redhat.com
Wed Mar 28 14:20:11 UTC 2012


On Wednesday, March 28, 2012 09:58:40 AM Mo Morsi wrote:
> On 03/28/2012 04:34 AM, Martyn Taylor wrote:
> > On 03/27/2012 07:42 PM, Jason Guiditta wrote:
> >> On 26/03/12 13:10 -0400, Matt Wagner wrote:
> >>> On Mon, Mar 26, 2012 at 04:54:41PM +0200, Petr Blaho wrote:
> >>>> Hi all,
> >>>>
> >>>> I am now working on preparing API for Provider and ProviderAccount
> >>>> resources
> >>>> so I want to ask some questions regarding controllers for API.
> >>>>
> >>>> At this moment there are some controllers in API namespace and so
> >>>> there is duplicated functionality between UI and API parts.
> >>>>
> >>>> In the future we will be adding features to API and CLI tool too.
> >>>>
> >>>> I think that we need to decide wheter keep UI and API controllers
> >>>> separated or merge them together.
> >>>>
> >>>> I think that best will be to merge them together.
> >>>> Controller should be as skinny as possible with minimum logic
> >>>> (parameters sanitizing, model call, render results - view or
> >>>> whatever).
> >>>> Controller should respond to html, js, json, xml, etc...
> >>>> All the logic now present in controllers should be moved to models
> >>>> or some other classes which will work with models (delegators,
> >>>> decorators, name it...)
> >>>>
> >>>> Please, write your thoughts and/or experience with this kind of
> >>>> problem.
> >>>
> >>> I agree 100%. We should not have a separate api/ directory of
> >>> controllers, especially not when they end up implementing similar
> >>> functionality.
> >>>
> >>> I do think we need to be careful about the fact that existing
> >>> applications might reference the /api URLs, though.
> >>>
> >>> -- Matt
> >>
> >> +1, was thinking about this before, and maybe we could just add a
> >> route to keep this uri path available?
> >>
> >> -j
> > +1
> >
> > I actually think that the /conductor URL should be for the UI only and
> > /conductor/api for the API.
> >
> > You could argue that the UI is simply a different content-type that
> > our RESTful API supports and therefore all requests are the same but
> > content-type is changed.  However, I would argue that we treat the UI
> > (in html) very differently from other content-types.  The UI has
> > server state, i.e. sessions (which are not RESTful) and also it
> > doesn't only deal with resources.  It returns a whole other bunch of
> > stuff for layout and styling.  This means that resources change
> > structure depending on where they are accessed.  They should be
> > consistent.
> >
> > In addition to this I would recommend keeping the UI and API methods
> > separate (but in the same controller) to keep things cleaner.  There
> > is a whole bunch of logic that goes towards layout, styling and a
> > whole bunch of extra stuff is in there that isn't really relevant (in
> > a RESTful API sense).  For example, there's probably multiple
> > unrelated resource sets in one page.
> >
> > Martyn
> >
> >
> 
> Thinking about it a bit while doing the security analysis, we have a bit
> of logic in the controllers that should probably not be there. Alot of
> the current business and transactional logic can be moved down to the
> service and model layers, while alot of the view / rendering logic can
> be moved into the helpers (eg anything involving the details pane / tab).
> 
> The controllers should ideally exist as a lightweight binding to these
> underlying subsystems, restricting access to certain data entities and
> fields as appropriate (though we don't currently do the later, a
> security issue as discussed in the rails security guide [1], more on
> this in a later security update) and formatting the data retrieved for
> use in multiple type of views (layout templates, json + xml API
> responses, etc)
> 
> In either case, if we merge the controllers or not, we should probably
> move towards this front, eg simplifying the controller logic as much as
> possible, which should give us a clearer picture as to what can be
> merged and what needs to be separated.
> 
>   -Mo
> 
> [1] http://guides.rubyonrails.org/security.html#mass-assignment
> 

+1 for thin controllers and move logic to service and/or model layer.

-- 

With regards
Petr Blaho



More information about the aeolus-devel mailing list