[LRUG] Encapsulation/Responsibility delegation and API versioning.

[Matthew Rudy Jacobs]

Given the problem space,
I would suggest you keep your api controllers fairly minimal
And instead encode the logic of any version specific api feature into a
proxy class.

Namely Aardvark::User is a nsmespaced proxy for the "Aardvark" version of
the api, onto the User model.

By default this proxy would defer all methods to the User class
But you can override anything.

I'd have an inheritance of these proxy objects like this

Aardvark::User < Aardvark::Proxy < ApiProxy

And see what requirements come out of this.
But I guess you'd end up with a dsl for relating a proxy class to its proper
class.
A way of delegating methods (or perhaps just defaulting via method missing)
And in each api version base proxy you'd end up defining the output helpers.


In some respect this is probably similar to what you already do.
But maintaining an object approach probably makes it easier to understand.
And more importantly to test.

On Monday, 22 August 2011, Ian Leitch <port001 at gmail.com> wrote:
> Hey list,
>
> I'm working on a Rails API that's the backend for an iPhone app. Given
> that I'll have no control over when a user maybe choose to up upgrade
> to the latest version of the app, I'm taking steps to ensure that each
> of my API versions are very much self-contained. When I need to bump
> the version, i'll simply duplicate the controllers.
>
> I've worked on apps before where you'd have multiple controller
> versions calling down to a shared model method - this is a time bomb I
> want to avoid.
>
> The smell that's now beginning to emerge is that controllers are
> getting fat with protected helper methods that build data structures
> for conversion into JSON. Normally I'd push these down into the
> model/some class, but like I said, I need API versions to remain
> self-contained.
>
> My initial thought was to suffix model methods with the API version,
> i.e attributes_for_json_api_v1 but that'll soon result in fat models,
> which I dont want.
>
> What solutions have other people used for this problem?
>
> I'm almost considering a layer in between my controllers and models,
> almost like a presentation layer from model to controller. Mixins
> could help here... perhaps something like this?
> https://gist.github.com/1162618
> Could get messy if the controller uses a large number of models?
> Thoughts welcome!
>
> Cheers
> Ian
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20110822/1941da14/attachment-0003.html>