A bombproof API: how to prevent your API from becoming a victim of its own success

3 min reading
Development / 15 September 2016
A bombproof API: how to prevent your API from becoming a victim of its own success
A bombproof API: how to prevent your API from becoming a victim of its own success

BBVA API Market

All developers would like their latest creation to become world-famous. In the case of an API, both its creator and the company launching this tool, which makes it possible to use and connect its services with the platforms of third parties, will be more than proud at their success. But not all that glitters is gold and this success could become quite a problem. 

In fact, if not properly created, an API might find itself overwhelmed upon becoming popular and collapse under an avalanche of requests. It is thus that uptime, the time of activity, becomes a key indicator that shows how useful and reliable the tool in question is. All developers aspire to their API reaching an uptime close to 100% and, the higher this marker, the more strength this API will show.

First of all, it is necessary to be aware of the limitations of the infrastructures that buttress the service: it is essential to know about the possibilities of the bandwidth to determine the number of simultaneous connections that can be accepted or the amount of data that can be transferred between the system and the users.  Thus, one avoids forcing both the network’s capacity and the architecture of the API itself and exposing it to the risk, deriving from its popularity, of an avalanche of requests resulting in catastrophe.

However, the supplier of an API has an ace up its sleeve in the event of success: rate limiting. This is the process whereby the API itself starts to reject requests according to various factors, ranging from the avalanche of simultaneous requests to the excess of data requested by one single user. This ensures the reliability of an API, as the system manages to remain at the disposal of users (albeit with the limitations imposed). 

This limitation, moreover, opens the door to a possible alternative business. It is not for nothing that limiting the speed would make it possible to offer subscription plans for those users who want a high volume of requests. With this freemium model (a free API for basic and paid accesses, created to increase the amount of requests), what in principle entails a problem and extra charges for improving infrastructures becomes a business opportunity.  

An indestructible API

When it comes to developing an API that can withstand attacks and avalanches, the gamut of possibilities for managing to create it is a wide one. For a start, in addition to determining capacity limitations, developers must also take into account such physical factors as the state of the servers in which the data are stored so that no breakdown will lead to an unpleasant surprise; the precise location of the cloud used for storing them; and its distance from the service users (the data, after all, take time in being conveyed and an excessive distance may be a problem).  

Besides, establishing server capacity limits that are too low or too adjusted to common activity may clog the service and cause it to collapse until it is impossible to connect to it. This is what is known in the Anglo-Saxon internet as the Reddit effect and in its Spanish-speaking counterpart as the “Meneame” effect: if a website, application or service manages to attract attention in the aggregator, it is best for the server to be ready for a multitude of requests that could undermine its stability.

Furthermore, and in order to ensure that an information transfer between the user and the API actually takes place whatever the conditions, it is necessary to take failover into account: establishing alternative routes so that, in the event of a failing, the exchange does not become blocked but merely has its route changed. 

For all of this to work ideally, the development equipment must also perfect the code as much as is necessary for it to contemplate all possible situations and include all manner of exceptions, ranging from possible memory failures to actual system overflow. Thus, the API will be able to react efficiently to any setback. This means that constructing a tool with the basic elements for its launching constitutes, on a mid-term basis, a serious, costly error that will cause the uptime to collapse in little time. 

Finally, and in order to avoid any kind of attack, it is best to be critical and use the API as a punching bag; the developer must be quite a white hat that explores the possible weaknesses and vulnerabilities of the API which may be used by an attacker to block access to the service – for instance, by means of a DDoS attack.

And we must not forget either that the solution to all the problems that may arise during the lifetime of an API must be compatible with its constant evolution and development so that it may remain a tool in a constant state of improvement. Its road to success will thus be much smoother. 

Are you interested in financial APIs? See BBVA’s catalog at this website

It may interest you