Merge / split controller for UI and API?

Jason Guiditta jguiditt at redhat.com
Wed Mar 28 14:37:04 UTC 2012


On 28/03/12 09:55 -0400, Matt Wagner wrote:
>On Wed, Mar 28, 2012 at 09:34:58AM +0100, Martyn Taylor wrote:
><snip>
>> 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.
>
>This is an interesting point. But I wonder if the answer might actually
>be that we're doing something wrong if our controllers are spending more
>time on UI setup than on their core function. Session should just be
>used for authentication (and stashing flash messages as a UI
>convenience), and the only change in resource structure should occur if
>you request that it be displayed a different way -- e.g., XML, HTML
>table view, HTML "pretty view", or JSON. You should have the same
>information each way, just formatted differently. If this isn't the
>case, I think we're doing something fundamentally wrong.
>
>> 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.
>
>But the whole problem is that right now the UI and API methods _are_
>separate, and this causes needless duplication and divergent code paths,
>where the API and UI methods inevitably do things a little differently
>with negative consequences. I would argue that, rather than separating
>them out, we should merge them and whip them into shape wherever making
>a UI controller method work for API calls isn't trivial.
>
>-- Matt

+1 to all your comments, Matt.  Someone else in thread already
suggested this, but if there is extra that a controller is doing for
the UI, not only would such differences be contained only in the
response block meant for html, but anything complex should be
extracted to a helper/module/something-not-the-controller.  Making the
actual UI controllers conform more to REST standards will improve the
quality of those controllers, and reduce the difficulty of building
out the api, assuming they are written well. 

-j



More information about the aeolus-devel mailing list