What is the Rails way to handle different controller clients (Web, iOS API)?

I have a Rails app that has 2 "clients" -- an iOS app reads/writes JSON, and Web browsers that read HTML.

Now, if I said "I want different output for different browsers/clients", we could use different ERB files and render based on User-Agent or similar.

In this way Rails was imagined in the Web world -- where I type "cap deploy", and all of my "instances" are upgraded to the latest version (save active session AJAX calls).

As an iOS dev, however, I'm very used to if blocks in code to deal with different data versions and client app versions. It's painful (but required).

I would love to be able to say "I will magically think of the perfect data structure in version 1.0", but we probably all know that's not true -- I'll want to add & deprecate attributes or even models as time goes.

I don't want to mix all of that versioning logic with my normal HTML (which can upgrade gracefully, per above), so I've thought about:

• Having a separate controller or just actions for my API calls from iOS
• Writing a "forwarder" that treats the HTML/Web version as a layer on top of the API version

Am I trying to solve a Solved Problem? Are there any resources or guiding philosophies I should know about in undertaking this project?

I suggest you create 2 applications, one for the webapp and one for the API.

You could have an external library with all the models, tests and business logic used in those 2 applications.

You can then lock the api to a certain version of the library if needed. You can create multiple versions of the API without affecting older versions. You can implement caching at library level if needed and it will automatically affect all applications.

With this model you can also create specific needs, for example, you may want shorter urls for the api than the real webapp, since you don't care about SEO in the API.

What do you think?

Edit :

Here is what I have in mind, library is in the middle.