Creating APIs Using Rails

With the advent of increasing numbers of single page and mobile applications developers are now more likely to use Rails to implement a resource-oriented API in place of more traditional HTML page-oriented applications.

There are quite a few issues and decisions that need to be made while implementing an API in Rails. This article is the first in a series where I’ll describe the technologies used in Rails APIs and the issues that need to be considered while developing one. In future articles I’ll cover each issue in more detail.

What Kind of API is it?

In this series of articles, we will be using the most common definition of a web services API: using the HTTP method verbs in a RESTful manner, usually with JSON as the data interchange format.

There are generally four different reasons why you would create a Rails API:

These different API types will often lead to different implementation concerns. For instance, for SPAs you have the benefit of cookies to preserve session state from request to request. You can use this to maintain the notion of a user being logged in.

For mobile and web-based service APIs you’ll have to do something like return a token when a user provides their username and password to log in. This token will then be used to prove the authenticity of the user in subsequent requests.

Finally, for SOA applications, the API servers may be running behind the corporate firewall and may not require any authentication at all.

Coming up

Future articles will cover the following topics in more detail:

If you’d like to be notified about future updates to this series, please sign up for my email newsletter at right.

comments powered by Disqus