Merge / split controller for UI and API?

Mo Morsi mmorsi at redhat.com
Wed Mar 28 13:58:40 UTC 2012


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




More information about the aeolus-devel mailing list