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