Servage Magazine

Building a fully functional API consists of multiple pieces that are eventually connected together, such as authentication, integration with external services and the core application logic. In this article we will see what it takes to build a full API and what you should consider when the time comes to build one.

Authentication

If you application has user accounts, you will need to handle authentication with your API. The first thing you should do is decide how users authenticate. Is it a traditional username and password combination, an API key, or perhaps something more advanced like OAuth 2? Either way, if your application handles login details, you should also set up an SSL certificate for your API.

Permission Management

If your website has users, it likely has user groups too. This means you have to implement a permission management system. The simplest approach is to have a database column in your users table called “role”. Some viable choices for the column type are an INT, VARCHAR or ENUM.

Whenever a user tries to do something, for example to modify the profile of another user, a piece of code is executed first to check whether the user has the correct role to perform that action. If yes, the execution continues normally, and if not, a permission denied error is returned.

CORS

If your front and back ends are located in a different address determined by the same-origin policy, you have to set up cross-origin resource sharing (CORS) on the API server. If you are on a shared web hosting plan, you can do this using the PHP header() function. If you have access to the configuration file of your HTTP server, you can also set it there.

Versioning

Versioning is something you should pay special attention to from the very beginning of development. If you believe your API will have multiple versions running at the same time, your API should be versioned. There are multiple ways to do this for APIs. Two popular ways are to send the Accept header from the front end to the API or to send the version in the URI of the API call, such as “GET /v1/users/1”.

The second approach is slightly controversial because it is not a fully RESTful approach. However, it is a very simple way and used by many popular APIs.

When you version your API, you can divide the core application logic into different namespaces and load code from a namespace based on what version the client requests.

Multilinguality

Is your application going to support multiple languages? This is something you should also decide as early as possible because changing from a single language to multilingual API can be a difficult task. If your API will be multilingual, you can return machine-readable messages to the client application, such as “ERROR.ACCESS_DENIED” and then map this message with the appropriate language file on the front end to find the corresponding human-readable message.

Deployment

When everything is done, it’s time to deploy your API. Once again, there are many ways to do this. You can use something simple and traditional like FTP, or set up an automated system with a deployment tool such as Capistrano.