What is Rails for handling different controller clients (Web, iOS API)?
I have a Rails application with two "clients" - an iOS application 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 rendering based User-Agent
or similar.
This way, Rails could be imagined in the web world - where I type "cover deployment" and all my "instances" are updated to the latest version (except for the active session AJAX calls).
As an iOS developer, I am very used to blocks if
in code to deal with different versions of data and versions of client applications. It's painful (but required).
I'd love to say, “I'll be worried about the ideal data structure in 1.0,” but we probably all know it isn't - I want to add and deprecate attributes or even models as time goes on.
I don't want to mix all this versioning logic with my normal HTML (which can update gracefully, as per above), so I 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 resolve a resolved issue? Are there any resources or guidelines I need to know when implementing this project?
source to share
I suggest you create 2 apps, one for webapp and one for API.
You can have an external library with all the models, tests, and business logic used in these two applications.
Then you can block the api for a specific version of the library if needed. You can create multiple versions of an API without affecting older versions. You can implement caching at the library level if needed, and it will automatically affect all applications.
With this model, you can also create specific needs, for example you can use shorter urls for the api than the real webapp since you don't need SEO in the API.
What do you think?
Edit:
That's what I mean, the library is in the middle.
source to share