Merge / split controller for UI and API?

Mo Morsi mmorsi at redhat.com
Thu Mar 29 20:34:48 UTC 2012


>>> 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
> I was not arguing against merging the controllers.  What I am saying
> is that the UI and the API are separate entities.  If you want to
> serve them both from the same controllers then fair enough that makes
> sense.  Helper methods can be written shared by both UI and API
> etc...   However, what I want to avoid is one massive method  that
> mixes the UI and API functionality.  What I was more envisaging the
> API methods to offer a native ruby content type.  That the UI methods
> can use.  For example:
>
> @image = Image.all
> when format.xml?
>   return @images.xml
> when format.json
>   return @images.sjon
> else
>   return @image
> end
>
> This way the UI methods can use the API methods in local method calls
> and then add whatever extra stuff it needs in order to make the
> service usable by a user+browser.
>
> regards
>
> Martyn

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



More information about the aeolus-devel mailing list