Merge / split controller for UI and API?

Scott Seago sseago at redhat.com
Fri Mar 30 14:25:20 UTC 2012


On 03/29/2012 04:34 PM, Mo Morsi wrote:
>
> I'm intrigued by this idea and don't think its a bad idea to explore
> this further.
>
> I think alot of the question comes down to at what level is the API
> satisfied. Currently it's being done at the controller layer in an 'api'
> namespace, but going along w/ your example I think its best the push
> this and as much else down to the service layer.
>
> This way the service layer can be used outside the scope of the web
> interface in a locally consumable manner. Perhaps this layer can also be
> moved into its own gem so that the end user doesn't need to pull in
> rails to use Conductor.
>
> Makes sense? Would this approach work?
>
>    -Mo
I think we're getting a bit far from the original proposal here. I think 
there are two different issues here that we're combining -- which makes 
deciding how to proceed more difficult:

1) Lets re-join the controllers that currently separate UI and API (in 
some cases they're combined in the same controllers/actions with 
different response types, in some cases (notably for image-related 
stuff) where the controllers are completely separate

2) additional discussion about whether API and UI are served by the same 
controller actions or if we separate the layers where the API is at a 
lower level and the UI controllers actually make API calls rather than 
the current "in the same actions" approach

So for 1) I think we've all agreed on the fundamental point -- dump the 
separate api controllers. Since we've pulled out 2) as a separate 
question, I think this means also keeping the same controller actions, 
using separate return types to distinguish API from UI actions. This 
essentially boils down to making Image controllers consistent with other 
controllers that don't have the separate API versions. Since we're 
trying as much as is reasonable to use RESTful routes for UI as well as 
API, making separate actions for the API (in the same controller) would 
prevent us from using standard action methods for either the API or the UI

on 2), I would propose that we do _not_ want the separation as you were 
discussing above. For one thing there's a lot of stuff you get in Rails 
for free to manage coordination between managing activerecord objects in 
controllers and views. If we have a UI that only talks to the API rather 
than manipulating models directly in the UI controllers, we'll have to 
do more work there. In addition, for ajax methods from the UI, we often 
want to get json back (rather than javascript or HTML chunks), which 
means that even in the UI we'll want direct json (i.e. API) responses. 
To ensure consistency in the UI between ajax calls and HTML calls (for 
non-javascript, etc.) we really want those going throuh the same 
controller actions.

However, even with the above point, I _do_ agree with making the 
controllers as thin as possible. There's definitely stuff in our 
controllers that belongs in the models, and there's probably UI-only 
stuff in our controllers that belongs in the views. Before talking about 
taking big chunks of the infrastructure and pulling them into separate 
gems -- we have to ask what the use case is. There's no point in doing a 
lot of work to pull something out unless you have a need to pull it out 
there. Lots of our code needs access to the ActiveRecord models, so even 
pulling things out won't remove all rails dependencies.

One other point -- regarding the issue around UI needing a lot of 
session info that the API does not (one of the justifications for 
pulling stuff out into separate layers), I'm not sure there's really a 
ton that we care about in the session other than login (and that's 
handled with HTTP auth in the API anyway, except for ajax-UI actions, in 
which case the session is available anyway). For the most part we 
shouldn't be relying on a bunch of stuff in the session between clicks 
in the UI if we can avoid it.

Scott




More information about the aeolus-devel mailing list