I have a Rails application that must serve an iOS app and the Web. At the moment, the Web controllers are acting as the API endpoints, too, albeit accepting JSON requests rather than HTML requests. Is there a best practice to separate these? Should they be separated?
Hi, thoughtbot released a new book (beta) iOS on Rails, it might help! (Haven’t read the book just skimmed through)
I read through the book and there is not an answer to this sort of question. In general, I wonder how developers separate the API controllers from the ‘Web’ controllers when there is such overlap.
I also wonder how prevalent the use of the device ID as proxy for username/password is. In my case, someone would likely register from the device with username and password and device ID and that would be sufficient to identify the user on both Web and phone platforms. But what are the downsides?
Concerning separating web controller from api controllers: They are being separated in the book by the namespace API. Just put everything related to the API inside it, and everything outside could be regular HTML pages.
Regarding device vs. user/password: One approach I’ve seen is that every user can have multiple api tokens, and that when an user logs into a new device, Rails generates a new token and with that the user can access all the other APIs (so, the only API endpoint with user/passwd authentication is the one to fetch the token). This way you can identify an user across devices.
I just started reading the book, but if I’d guess why we’re using devices to authenticate a user as opposed to user/passwd, I’d say that this is fairly reasonable for a new app because you really shouldn’t care how users access your app until you’re sure your app works by doing what was proposed.
I can separate by namespace, but that’s not my issue per se. I have a great deal of crossover between the two controllers; in some cases, the only difference may be the format of the response.
I could have a base controller and two subclasses. I suppose this would give me a basis for divergence in the future, if need be. I was hoping someone could weigh in on options.
If you’re talking about something similar to i.e. UsersController vs. API::UsersController, just let them be different entities, even if entirely equal. You can extract similar logic to services like this, but if they are both really simple, I wouldn’t mind their similarities for now.