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.
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'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?
I have a WordPress site and a Rails site hosted on separate servers. I need to pull information from some custom post types on the WordPress site and display them on the Rails app. At a minimum, I would like to display all the post titles (hyper-linked) – there's no writing to WordPress needed.
I'm not well-versed in Ruby on Rails or HAML – I'm basically just a WordPress/PHP developer – so I'm at a loss as to how to begin. I'm thinking the best way is to pull data from WordPress using the WP REST API (http://v2.wp-api.org) plugin, but I don't know how to go about rendering data from an API in RoR/HAML. If you could point me in the right direction, that would be awesome!
Yep exposing an API on the WordPress side would be a good option, you're on the right lines.
In this situation you could do is start by creating a controller, route and view (hopefully some tests too) then within the controller you can request the data from the WordPress API. For this you will need a HTTP client, Net::HTTP is part of the Ruby stdlib or alternatively something like faraday which offers a little more flexibility. From here you can pass the response data into an object that you can use in your HAML views as required. You don't want to be assigning the JSON to an instance variable in your controller and accessing it as a Hash in the view, create a class that parses the response and provides some methods to allow you to access the data using method calls.
This would get you going in terms of a basic implementation but once you get the basics working it may be worth doing a little refactoring. For example what you would have now is a small wrapper around the API and this could be a logic extraction from your controller. The advantage being that the controller code becomes easier to understand and also should you wish to use the wrapper somewhere else within your application that becomes much simpler.
Edit: You could also use a REST ORM like her
Given the current Rails security alerts going around, I'm looking at securing applications for a few apps. Most of them barely make use of the XML/JSON parsing and when they do it's to integrate specific pages or hooks with a 3rd party service.
I've seen the ability to delete default parsers to turn the functionality off completely, but is there a way to enable it / whitelist it on specific routes that may be protected by http basic auth or some other means? That would at least require somebody attempting to exploit these types of vulnerabilities to know the specific locations where it's enabled.
The primary risk of the current XML/YAML parse vulnerability has to do with the callbacks that give you richer re-serialization for objects. So one possible way to do this is to just use the lower level APIs that give you parse trees for the XML/YAML, but don't do any hydration beyond Ruby scalars (strings, numbers, hashes, etc). If that doesn't work for you, using a parser like Yajl or, in many cases, just upgrading to the latest versions of the gems, is sufficient to allow parsing to remain on.
Also, the primary risk of the parsing is in the parameter parsing, not response parsing. Response parsing (especially if you can trust the service, and communicate via a secure channel), is a much lower risk since you can control when and where it happens.
The behavior you're talking about is implemented as Rack middleware, which processes the incoming request before it gets to your controllers.
This middleware is what acts on the list of parsers enabled for different mime types. You can patch this behavior by re-opening it if you want to add custom rules for when different parameter parsing logic is used on a given request.
Here's a link to the source.
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.