I've come across two scenarios with regards to creating a REST API in Rails and I wonder which one is preferred. Usually
if you know that you're required to have a REST API for your application at start. Does it make sense to have it in a namespace and thereby duplicating the controller logic?
I've seen examples where people have an application already and later figure they need to extend and offer a REST API. The approach to this has been to create new routes with namespacein routes.rb and controllers/api/whatever.... This still yields duplicate code though, but might be more sensible approach. The difference being a stateless machine for the REST API calls.
Can anyone elaborate on the preferred approach, thanks.
If you create a Rails application, and following the usual conventions, you basically end up with a REST API. Unless you are talking about a more specific meaning of the term (which I am not aware of), "REST API" is more a bunch of general characteristics of the API (i.e., things like statelessness, resource-based URIs if using HTTP, etc.).
So to turn the question right back to you: which case are you thinking about where a (conventional) Rails application is not by extension trivially a REST API?
Related
Just been researching about this approach and never seem to find a concrete answer online.
I'm seriously curious about the chances of only consuming the API for activeadmin. Then using the JSON objects in React or Angular with a custom UI.
Is this doable?
Absolutely! See https://blog.heroku.com/a-rock-solid-modern-web-stack
For notes on ActiveAdmin vs Rails Admin and other alternatives see https://github.com/activeadmin/activeadmin/wiki/Alternatives
I've also used both Grape and GraphQL in different places, one for performance, the other for flexibility, both reasonable choices.
In theory it is possible since you would just be using the endpoints provided but I think it would be far a far better design choice to choose another API framework gem like grape. One of my complaints with ActiveAdmin has always been that it is not very flexible and you can quickly run into limitations which means that you can't add features that you want to. IMHO you would be digging a pit instead of opening possibilities.
Personally I really like GraphQL (which would be another option) and the graphql-ruby gem is easy to set up and start making highly reusable components that can be leveraged from anywhere admin or frontend.
I have a web application that also provides an API. The API is fairly simple, so I am just handling it in the respond_to block and returning json if requested. Now I want to version my API. I was looking at versionist gem. This mentions using the api_version method in your config/routes.rb to change routes based on API version. I don't understand this though, since I would think the routes would be the same, but the behavior of the response would change.
My question is, do I need separate controllers for my web and API portions? Also, do I need a separate namespace for the API? Or is there a way to keep things as they are now?
There are some things you'd want to do differently when providing an API. One of them is the ability to set an API version so that you can enhance your API by adding a new version without breaking existing clients. If your API is extremely simple you can achieve this by providing a second set of routes that will include the version. You may use versionist for that. However, when you'll need to add versions, the simplest solution (and the one that keeps concerns well separated) will be to hold a separate set of controllers, and keep them thin so there is no code duplication. This may allow you to use additional gems for the API (e.g. RABL, JBuilder or rocketpants). There are railscasts on each of them, I recommend watching them to get some background on API building.
I was reading through the RABL git https://github.com/nesquena/rabl and I quickly came across this line. Can someone quickly explain what he means by "generating APIs"?
When using the ActiveRecord 'to_json' method, I tend to quickly find myself wanting a more expressive and powerful solution for generating APIs.
From my understanding an API is a set of classes / methods that may be used to interact with the content of the API creators material. With that definition, I believe he is saying that he wants to be able to interact easier with the API so he build RABL which allows for the content to be translated from his application to, in this case, Rails eaiser?
In this case, API is applied to the system as a whole. So your entire website might have an API that your customers would use to pull/send data to your system.
Mostly, these are JSON/XML endpoints that accept and return data. Rabl (and other serializers like it), help you craft custom JSON responses.
I am planning a system that requires collaboration between many local Rails apps. The design calls for a global app to relay RESTful requests between these servers.
For example, imagine each school having a local Rails app, including a Teacher resource. I propose a global app which provides access to teachers as: /school/42/teacher/3
The School resource on the global server has a field for the base URL of the app at each school, so it can relay such a request to school_42_url/teacher/3.
The design calls for relaying, rather than having school servers connecting directly to each other.
I can think of several ways to achieve this but, being new to Rails, can't work out which one is 'the Rails way'.
ActiveResource is appealing, but seems to require a fixed 'site' rather than setting it for each request.
Routing, perhaps with URL globbing might work, but I need to see an example of how to achieve this.
A third approach would be a custom Controller, but this doesn't feel like the Rails way.
To be clear, the combination of {school_id, teacher_id} is globally unique, but the global server need not store details of teachers, those are treated as a web resource.
Comments or suggestions welcome.
You should use rails RESTful architecture on your client apps to expose apis (xml, json), and some library like Net::HTTP to call those apis from your server(main) app.
It sounds like Pow may be what your looking for. It allows you to configure URL's for stack and rails application via symbolic links. It fits well in the rails model and may allow you to build your independent RESTful applications in the manor specified. I know their are methods for having independent rails servers work together but based this is a very low overhead approach and may be the way to go at-least for testing and development purposes.
I am pondering on using a Restful implementation in Rails. I'm asking myself if it's the way to go.
Should I always go for a Restful implementation or not?
I think there really isn't much other option as far as Rails goes. You would just be fighting against all the design decisions and sensible defaults that Rails, as a framework, has already made for you.
Think about all the provided shortcuts for routing, pathing, forms, etc. I think you would end up just spending more time/effort on a non-RESTful implementation.
The first thing to sort out is what REST really means. Fundamentally it is about utilizing HTTP efficiently and correctly. That is, GET requests don't modify anything, PUT requests are idempotent, etc. The notion of uniquely identified resources just sort of falls out of this optimal usage of HTTP. The beauty of REST is that you gain the maximum programmatic benefit out of HTTP, making things like caching, proxying, and automatic retrying able to work fairly well without any knowledge of the application whatsoever. Dare Obasanjo wrote a nice rant on the topic of REST misunderstanding. This contrasts heavily to something like SOAP where you have an heavyweight envelope format that uses HTTP as nothing more than a glorified transport layer.
Now when it comes to Rails REST there is a whole nother thing going on, and that is Rails' convention over configuration. Rails REST is just a thin baked-in layer of tooling to make it easy to define CRUD operations on resources you define. Note that these resources don't need to correspond to ActiveRecord models, and certainly using Rails resource routing is not a pre-requisite for designing a RESTful application. What Rails gives you is an extremely handy default for dealing with things that fit the model of a CRUDable resource, however you shouldn't hesitate to define additional methods on top of resources, or to forego resources altogether if you have pages that don't really seem like resources (eg. reports).
The bottom line to keep in mind is that it's not one or the other. Rails RESTful helpers are using the same primitives that have always been in Rails. You can use both together and they jive nicely.