Merge / split controller for UI and API?

Martyn Taylor mtaylor at redhat.com
Mon Apr 2 10:04:47 UTC 2012


On 03/30/2012 06:39 PM, Jason Guiditta wrote:
> On 30/03/12 10:25 -0400, Scott Seago wrote:
>> 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
>>
> +1
>
>> 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.
>>
> I agree that we should hold off on 2, taking the steps mentioned to
> remove as much logic form the controllers as possible, but I don't
> think Martyn was suggesting a separate gem here, or even ripping out
> the api methods into another class or controller. Rather, I read it as
> 'lets make the api actions on the existing controllers be more pure
> rest, and any non-rest stuff goes into separate actions, calling the
> rest ones inline as simple methods'. 
Yes that is exactly what I was trying to suggest.
> While I can see, and to some
> extent, agree with this line of thinking, I do not like where it takes
> us, namely divorcing the ui from being at all restful, and instead
> having all custom methods. 
I don't think the UI should or has to be RESTful.  IMO it is a service 
that is built on top of the API and should be free to do what ever it needs.

> I think this is in contradiction to the
> general flow of a rails app. 
Fair point, A lot of rails applications service the UI and API from the 
same endpoint and thus the same action.

> If you have (smallish) extra things that
> need doing for a UI, those can be done in the block of the response
> that returns html.  If there is anything complex, that should be
> extracted, and in the (I would think very rare) cases where that is
> not possible for some reason (say something needed only for an
> ajax call) the developer could consider either a custom action, or a
> metal controller (or whatever the equiv is now called in rails 3.x).
Sounds like a reasonable approach.  Though I think this still doesn't 
address my concern that I feel that the API and the UI and 2 completely 
independent resources and should not be realised from the same endpoint.
>
>> 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.
>>
> Yes, if the UI is doing too much with the session, that is a bug, not
> a reason to separate out the actions. I do not think it is currently
> doing all that much though.
I wasn't suggesting that there was a lot of stuff in the session.  I 
used the session merely as an example to show how the UI is not RESTful 
and as such should be separate.  In my opinion separate means a 
different endpoint, which would also mean a different controller#action.

Thanks

Martyn

> -j




More information about the aeolus-devel mailing list