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
>> 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?
> 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
> want direct json (i.e. API) responses. To ensure consistency in the
> 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
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.