Shayan Sobhanian Json Response-7988855542

Using Rails for API Servers

Back in 2004 when Rails was first released to the world, the connected world was a very different place.

Very few web sites offered API access, and those that did usually exposed the API using SOAP, XML-RPC, CORBA, or their own unique quirky API protocol. There was no common consensus on authentication methods, so some allowed tokenized access and some relied on HTTP Basic. The output of the APIs was usually XML.

While both the RESTful architecture style and JSON as an output format had been around for many years, neither had yet been universally adopted by the web development community.

The majority of mobile phones had small 128×128 pixel displays, 3G rollout was still in the very early stages (and the corresponding data allowances were tiny and expensive) and most mobile application development was limited to small J2ME applications with limited functionality. Therefore, the developer demand for APIs was still small.

Web applications all used the traditional full-page reload for each request and use of JavaScript was limited to small, snippets of functionality.

However, obviously, a lot has changed since then. The use of connected devices has grown astronomically in the last decade, meaning your application is likely to require an API for iOS and Android applications. It is now common to be requested to build a purely API-driven application that has no web interface at all, both to serve as back ends for mobile and desktop apps. Advances in JavaScript mean that it’s now possible to build highly interactive, complex browser interfaces that purely use the server via an API rather than relying on traditional HTML server responses. Also, the rise in adoption of microservice architectures means that more than ever, Rails is being used to build API-only applications.

Rails has long provided ways of allowing creation of APIs, but with the inclusion of the Rails API project into Rails itself, there is now a standardized way of doing this.

The Rails API Project

The Rails API project started in 2012 as a gem that provided a way to generate a Rails application excluding parts of the framework that aren’t necessary to create an application with no HTML front end. Over time, it kept up with the Rails releases, became more configurable and now, with the release of Rails 5, has been merged and become part of the framework itself.

JSON Response Creation

By default, a Rails 5 API-only application just relies on the to_json method of each model to generate the JSON output, but you will likely want to make use of a serialization library such as JBuilder or Active Model Serializers.

In this book, we will look at the Active Model Serializers gem. The Active Model Serializers library was part of the Rails API project and was originally planned to be the default for Rails 5 API applications, but this was changed in the Rails 5 beta releases and now it ships with no default library.

Active Model Serializers

Active Model Serializers (often referred to as AMS) allows you to easily create serializers for Active Model objects, encapsulating all of the serializer logic for each model. Out of the box, Active Model Serializer understands Active Model objects and it follows the Rails convention of using current_user for the authenticated user object. Because of this, creating JSON or XML serializers for APIs is made elegant and simple.

Most interestingly, maybe, is the support of the JSON API adapter. The JSON API project is an attempt at creating a standard convention for JSON API responses. This includes standard syntax for embedding related objects, links to other objects and pagination links. AMS allows different adapters to be used, so use of the JSON API adapter is not mandatory; by default, a simple attributes adapter is used.

While there are a vast number of alternative JSON serializer projects, AMS has gained a huge following and has become the preferred solution for a large number of developers.