The article deals with possible pitfalls of building an API with Ruby on Rails.
Controllers. If you a Rails developer and you decided to create your first API, there are a lot of things you should take into account. First of all, you should choose the right controller. If you want to get a fast API, we recommend you to use ActionController::Metal instead of ActionController::Base. The latter has many unnecessary middlewares while Metal controller includes basic modules using which you can speed your API up to 40%.
The following picture shows how your basic Metal controller will look:
Since Metal is not supported by NewRelic by default, you’ll have to add monitoring manually.
Obviously, your API will undergo numerous changes, so it’s important to use the right versioning from the start. BaseController is wrapped in V1 namespace. Enter something like this in your routes:
In order not to complicate your code with different model fields for different API actions, use a template engine, for example, RABL. This is how your view will go:
It has another benefit – you won’t need any respond_to blocks:
You can leave those lines empty:
But make sure there is an RABL view in a corresponding directory.
You must have heard that an API can be secured with OAuth. But there is an easier way to protect your API – just use token in the query string. If you ended up with token, keep in mind that you can easily generate it by calling SecureRandom.urlsafe_base64. To check if token is unique, do the following:
Hiding your IDs with GUIDs
In Rails, incremental integer is used for the primary key by default. However, this kind of IDs is not usually shown to other users via your API since some of them might guess other IDs in your database. It poses a potential danger, so you need to devise a simple algorithm that will convert the IDs into a more secure form. Still, the algorithm can’t be 100% unique and secure. Fortunately, there is a solution: GUIDs – 128-bit values displayed as 32 digits:
It’s generated in Ruby with the help of SecureRandom.uuid (generates V4 GUID).
It can be stored as a simple string column but if you are using Postgresql, you can utilize its built-in uuid type that will save you a lot of space.
Rails uses:string for the uuid Postgresql native type. To start working with it, create a column manually in your migration (index should be added as well):
To use uuid_generate_v4 function you have to add Postgresql extension:
And don’t forget to change the format to :sql in config/application.rb
Testing your API
When everything is done, you’ll want to put your API to the test. The table below shows what can be done with Rack::Test::Methods:
Building your first API, you’ll face a lot of challenges. Hope, the tips and tricks covered in this article will help you avoid potential troubles. Take care of documentation – users appreciate it very much.
Article is prepared by ruby on rails developers from outsourcing product development company RW located in Ukraine and Poland.