Given the problem space, <br>I would suggest you keep your api controllers fairly minimal <br>And instead encode the logic of any version specific api feature into a proxy class. <br><br>Namely Aardvark::User is a nsmespaced proxy for the "Aardvark" version of the api, onto the User model. <br>
<br>By default this proxy would defer all methods to the User class <br>But you can override anything. <br><br>I'd have an inheritance of these proxy objects like this <br><br>Aardvark::User < Aardvark::Proxy < ApiProxy<br>
<br>And see what requirements come out of this. <br>But I guess you'd end up with a dsl for relating a proxy class to its proper class. <br>A way of delegating methods (or perhaps just defaulting via method missing) <br>
And in each api version base proxy you'd end up defining the output helpers. <br><br>In some respect this is probably similar to what you already do. <br>But maintaining an object approach probably makes it easier to understand. And more importantly to test. <br>
<br>On Monday, 22 August 2011, Ian Leitch <<a href="mailto:port001@gmail.com">port001@gmail.com</a>> wrote:<br>> Hey list,<br>><br>> I'm working on a Rails API that's the backend for an iPhone app. Given<br>
> that I'll have no control over when a user maybe choose to up upgrade<br>> to the latest version of the app, I'm taking steps to ensure that each<br>> of my API versions are very much self-contained. When I need to bump<br>
> the version, i'll simply duplicate the controllers.<br>><br>> I've worked on apps before where you'd have multiple controller<br>> versions calling down to a shared model method - this is a time bomb I<br>
> want to avoid.<br>><br>> The smell that's now beginning to emerge is that controllers are<br>> getting fat with protected helper methods that build data structures<br>> for conversion into JSON. Normally I'd push these down into the<br>
> model/some class, but like I said, I need API versions to remain<br>> self-contained.<br>><br>> My initial thought was to suffix model methods with the API version,<br>> i.e attributes_for_json_api_v1 but that'll soon result in fat models,<br>
> which I dont want.<br>><br>> What solutions have other people used for this problem?<br>><br>> I'm almost considering a layer in between my controllers and models,<br>> almost like a presentation layer from model to controller. Mixins<br>
> could help here... perhaps something like this?<br>> <a href="https://gist.github.com/1162618">https://gist.github.com/1162618</a><br>> Could get messy if the controller uses a large number of models?<br>> Thoughts welcome!<br>
><br>> Cheers<br>> Ian<br>> _______________________________________________<br>> Chat mailing list<br>> <a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>> <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
>