Problems API providers experience

When building a web API your first focus is getting it working. Depending on the framework you use and the kind of application you build this can be achieved quite fast, for example when using Ruby on Rails I can have a simple API up and running in a few hours. However, that’s just the start. Don’t underestimate the importance of a good API interface design, fast responses, good rate limiting and monitoring.

API design

When you have to change your URL structure, parameters or contents of your API responses you’ll need to contact the users of your API and make sure they implement them as well. A common technique to simplify this would be to introduce a new API version. I try to use a simple version number in the URLs of the APIs I design. For example, I use /api/v1 for my first API version. When something seems to hold me back and I really need to introduce backward incompatible change I start to build /api/v2 and advise all my users to start migrating to the new version.

Request response times

When the first users start to use the API they won’t generally hit a lot of bottlenecks. Those are generally encounted when the product really start to scale up in usage amounts. It can be quite hard to track response averages and find outliers. Most development frameworks only provide you with some log entries that could be analysed with some grep and awk trickery. This is why I build <a href=”https://callcounter.io” target=”_blank” rel=”noopener”>Callcounter</a>, it gives the API provider a simple and straightforward interface to analyse the response times and filter for certain URLs, methods or user agents to discover the actual bottlenecks.

Rate limiting and monitoring

If usage really takes of there will almost certainly be misbehaving users. This could be due to programming errors such as accidentally running every second instead of every hour, but also genuine bad actors. This is were an introduction of rate limits seems usefull. This can be achieved with products such as <a href=”https://github.com/rack/rack-attack” target=”_blank” rel=”noopener”>rack-attack</a> for Ruby on Rails. They can be configured to allow a certain number of requests from a certain ip address or authenticated user. With rack-attack in particular you can even limit certain HTTP methods or URL paths.

Finding the limits that normal users should never hit can be quite difficult with only framework logs. This is where <a href=”https://callcounter.io” target=”_blank” rel=”noopener”>Callcounter</a> can really help. Filter by user agent and find the biggest customer. It will show the paths they use most and also the times of day, week and month where they are doing their most requests. Callcounter can still be used after configuring the API rate limits to keep verifying that important customers are not hitting the rate limits of the API.