With the introduction of rails API only mode, there is a wealth of documentation on how to create API only applications. There is also a wealth of information on how to create regular rails applications. But what if you want to do both? What if you want a web application and APIs for native mobile applications in the same code base? So far it’s not clear to me what the rails way of doing this is, if there is a rails way to do it, or if the consensus is that you shouldn’t do it that way.
I know that rails controllers respond to json out of the box, so it is possible to get the data that would normally be displayed by the view via a call to the route with .json appended. But that doesn’t solve the problem of how you would authenticate the mobile application/mobile user alongside web users. I’ve found a few resources that provide workarounds for the token problem:
What I would like to see is official support/documentation for running a traditional web application with HTML views (and cookie/session based authentication) alongside an API that is used by native mobile applications (using tokens or other mobile friendly authentication methods).
This kinda feels like it’s related to rolling authentication into rails core. Maybe it will be easier to do this if authentication was part of rails core. But some documentation would still go a long way in helping someone who is doing this for the first time.
I think this might be a place for “document, then automate”. I see the steps as:
Establish a “cowpath” for mobile authentication in Rails applications that support both a conventional server-rendered Rails web frontend and a native mobile application frontend. (It sounds like you’ve already blazed that trail!)
Make that cowpath easier to follow by documenting it. I think that a lot of the effort on documentation would be about organizing what the approach looks like, and linking out to or quoting existing documentation on specific pieces of that approach.
Looking at that documentation and asking, “what parts of this require a human to do stupid configuration situps, or copypasta standardized recipe code?” Those places are missing features.
Implementing those missing features in a gem or gems, which lets folks opt-in to beta testing implementation of those features.
Working to pull those gems into Rails.
That is not a short process! But if we turn it into tiny little steps, we turn it into a project that anyone can work on incrementally.
Who reading this has the time and energy to work on step #2 of documentation?
I’m willing to help with the documentation However, I will preface this by saying that I am relatively new to rails development. And while I have managed to get this working in my project I don’t understand why it works, or why I needed to do the steps outlined in those posts. The posts did a great job of explaining what needed to be done, but not why they needed to be done, and how they change rails behaviour to get stuff working. Also, I was very surprised (thrilled actually) when I recently tested accessing other .json endpoints using token authentication and they just worked. I don’t know why they work!
So in summary, I’m happy to work on the documentation, but I’m going to need help to understand the why of things. I could start by creating a skeleton of what needs to be done, based on my working implementation (which I got working using those blog posts). I could make note of the sections that I don’t understand, and someone who does could fill that in? Ultimately I foresee a document which someone who doesn’t understand this could pick up and implement, but also understand what they are doing.
It basically replicates what I did on my first attempt based on the blog posts that I linked to. The README outlines the steps that I followed to get it working. I tried to keep the commits in line with the step by step instructions. I also left the branches around in the GitHub repo for reference.