I'm developing a rails app, it's a regular site, but I need to develop an API, so I was reading and trying some stuff, the options that I've thought are (others are welcome):
Versioning the API and separate the API from the controller.
Pro: Clean and separate stuff. Cons: the need to handle 2 controllers for the same task.
Not versioning and keep everything in the same controllers, views can be done with jbuilder. Pro: not really easy way to version it. Cons: harder to expose only parts of the app. harder to route stuff like in an versioned way.
I really want to avoid duplication, but I need some way to avoid that, and make some nice routes like in a versioned way, I don't want to have more than 1 controller for some type of object, in a versioned way if you have 3 versions you'll end up with 4 controllers, that is a lot to maintain.
Please correct me if I'm wrong, and hope to get some good answers :)
Thanks.
Versioning your API is the best route to take.
If you have 4 versions, 1 controller, you still only need to maintain 2 controller (the one in the web facing application, and the most recent version of the API.)
If you have write access in your API, you would be able to take advantage of your own API in your application and not need to create a new method in both the API and in the main application (AJAX).
It is possible that your filters are different. You may need different types of authentication for the API and the main application.
The biggest argument for versioning would probably be that if you have anyone other than yourself consuming the API, their application would not break the day you deploy your changes.
Besides, you should keep to the 'thin controllers, fat models' mentality. That would prevent a lot of duplication with that alone.
I always code api within their own namespace because these points could be very different from the main app:
format rules
auth
rescue
versioning
before / after filters
Even if you have duplication in controllers, there should not be much code, and I cant see why it would be a big deal. Actually it could even force you to abstract your code and have thin controllers.
Related
We are in the progress of building/migrating new features into our web application. We have a namespaced API (V1) that the mobile applications use to communicate with the app.
While we are in transition (we will launch the features for the web first), how can one differentiate between API requests and web requests, for purposes of bifurcating the logic in the shared model files? We need the models to stay the same for the mobile apps, but be different for the new big web-based features. Unfortunately code like
request.format
Isn't available in models.
Or is there a way to tell the API controllers to use different model files, and have separate models for some API vs. web app controllers?
I know that you should put as much code as possible within the model, however does this particular piece of code belong there?
It begs the question, because this seems to be 1) presentation oriented and 2) concern with the state/request.
It makes me believe that this code should actually reside within controllers.
API controllers to use different model files
Ofc, just use a different model...
You've provided little information about what you're trying to achieve, which makes things difficult.
However, this seems like some presentation oriented code based of a web state.
There for, add decorators to your application and do your conditional presentation there.
I have a project that involves both mobile and web clients. The mobile clients will mainly get content and post user updates, while the web client is mainly for creating content. As such, the web client and API share a lot of the same models and validation.
I am trying to decide the best approach in this case:
JSON-only Rails API + separate Rails web client that calls API.
Single Rails app with separation of API and client side (somehow).
The pro for me in terms of option N°1 is the separation of concerns, as I can work on the API while someone else do the web client. The con seems to be lots of duplicated code in terms of validation.
N°2 could make more sense in terms of reducing code duplication but it would get messy if more than one person is working on the same code base and setting up a process to resolve code conflicts is not something I want to do at this point since we're an early stage startup and want to get out something quickly.
Is there anything I'm missing?
The best practice is use ONE rails application for API and Web Interface
To separate those parts, just create a namespace for API like it's described there http://collectiveidea.com/blog/archives/2013/06/13/building-awesome-rails-apis-part-1/
Do it in one.
The con seems to be lots of duplicated code in terms of validation.
No, you would not have duplication the validation happens in the model, which is shared by your API <=> web controllers. Of course, you will have separate implementations for the actual authorization/session handling (if you have those), but these will not likely be duplicate but a bit different for your two access layers.
I've read quite a few articles on good design for Rails APIs. However, I can't seem to find what I'm trying to do. And it's different enough that I'm not sure what to do.
So this Rails site has forms for generating various records for my various tables. It all works fine. No problem there. This is all admin-level stuff.
However, a few of these forms need to be also be available as an API. Right now my APIs work fine but it's poor design (I think). Currently the user will make an API request to do some action and pass some information in (i.e. add record to Foo).
My method inside the API, special_new_foo, more or less duplicates my create inside the foo controller that a form would route to. Is there a way I can reuse my standard create method? The API would then just check for good data, etc. and pass the information onto the controller...
I was thinking about just making an HTTP request to the local server on the machine (which is basically how the forms work, except they're two separate machines). Is this good practice?
Thanks!
One option is to allow you controller to respond with different formats, depending on the request. I think this is what rails generates on scaffolding. However i barely saw any real world app doing this. See also my answer to Is it necessary to build a separate API endpoint for mobile apps to access a Rails web app?
A better solution is to make an extra ServiceObject or FormObject dealing with business logic of your controllers and reuse this object in both endpoints
see http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
I'm building a iOS mobile application with a Rails backend.
This is my first programming endeavor.
At first when I started building the API I created a separate namespace for it and the controllers would respond with "render: json." Now, knowing a little more about routes I realize that I can set a respond_to and respond_with in the controllers thus eliminating the need for any separation. Assuming that at some point there will also be a web application along with other mobile clients is this the best approach? Will this offer more flexibility for programmers who may want to refactor the code later on or vice versa?
I saw this question asked but it offered a solution that separates the API entirely and then utilizes Backbone for the web application front end as the best option. There was no insight into the approach I'm thinking of using.
Generally speaking yes this is the best approach. You will basically create a new set of controllers (typically in a folder called /api/) where all of your API controllers using Rails_API will be housed. This means you will potentially have 2 + n controllers to maintain in the future. 1 set of controllers for the web app (standard rails controllers), 1 set of controllers for v1 of your API and "n" controllers for subsequent versions of your API. More information on why APIs need versions here. The problem in the future will be a large maintenance task (depending on the size of your app).
I've been toying with the SimplyRestfulRouting assembly that comes with the MvcContrib extras, and for the most part I really like that it quickly sets up my routes and leaves me with a good convention to follow in my controllers. However, I'm still trying to wrap my head around REST as it applies to rich internet applications and occasionally feel pigeon holed when I need to do something that falls outside the scope of those 8 or 9 default routes. [Edit: By "pigeon holed", I simply mean I feel like I'm dirtying up the application when I have to create a controller action that is outside the definition of the default "restful routes".]
I heard a comment from a REST proponent in which he stated his opinion that the MVC framework is inherently RESTful, and it got me thinking a bit more about what libraries like the MvcContrib SimplyRestfulRouting are actually buying me.
Not having read a lot about the concrete pricinples of REST, I'm looking for input as to what benefits might come from enforcing such a thing in the context of a forms-over-data, RIA. And with regards to AJAX, how does a RESTful architecture affect my client interaction?
It's likely I'm misunderstanding the use of REST in this context, and would appreciate some StackOverflow mojo to get my head on straight.
The main benefit I can see in enforcing RESTful routes -- regardless of the framework used -- is consistency. You'll always be able to know how the API will work for any resource, which will in effect give you a self-documenting API.
It also provides a wonderful constraint while architecting the application. Rather than having an API with a blank slate that could get complicated very quickly, constraining the routes to the basics will give you guidance as to which resources you'll need to create.
For more of the basic principles surrounding REST, I'd recommend reading this thread.
Being RESTful is more than just having clean URLs.
At an architectural level, REST is about organizing your application functionality in terms of resources, and exposing a fixed and uniform set of CRUD operations on them (e.g. HTTP POST/GET/PUT/DELETE methods). This is known as Resource Oriented Architecture.
In contrast, with Service Oriented Architecture you typically organize application functionality in terms of processes or components, and expose non-uniform, application specific methods on them (e.g. via SOAP).
Note, you can have clean URLs but still end up following non-RESTful SOA design principles.
UPDATE: Sorry, didn't really answer the question, got hung up on use of "RESTful" terminology. If you're just talking about the benefits of clean URLs (REST/SOA argument aside), the typical argument is better SEO optimization and user-friendliness (user can better make sense of and modify URLs).
the advantage is that if you have some adress and from that adress you getting something, then you can call that adress from anywhere you want in you code, and you will get exactly same thing :)
and in concrete example, if you have route that can return some html full with data(user control for example), then you can call it from ajax, from your desktop application or even from your web service...it is very powerfull because you WILL have some functionality repeated over your application...and because some html that you getting from that restful service giving you exactly one view with exactly one functionality, you can call it dynamically from dialog or from page or from your desktop application or from anywhere...
and when you add to this that you can call this adress with parameters, exactly like some method, you can now see how powerfull this can be in creating dynamic pages and web sites/systems
hope this helps