A Simple Guide to API Development Tools

APIs can be as simple as 1 endpoint for use by 100s of users or as complex as the AWS APIs with 1000s of endpoints and 100s of thousands of users. Building them can mean spending a couple of hours using a low-code platform or months of work using a multitude of tools. Hosting them can be as simple as using one platform that does everything we need or as complex as setting up and managing ingress control, security, caching, failover, metrics, scaling etc.

What they all have in common are three basic steps to go from nothing to a running API.

Each of these steps has its own set of tools. Here are some I’ve used and popular alternatives.

REST is the most popular API interface and has the best tooling. Our design output for REST services always includes an OpenAPI specification. The specification language can be tricky to get right in JSON (how many curly brackets?) or YAML (how many spaces?) so a good editor saves a lot of time.

Four popular ones are:

I’ve only used Swagger and Postman but both Insomnia and Stoplight look interesting. All of them offer additional functionality like documentation, testing and collaboration so are much more than just specification generators.

I want to keep the time I spend building, maintaining and fiddling with infrastructure to the minimum so I make extensive use of services for database, email, queue, security or other commodity type functionality. The services I’ve used and some of their alternatives are:

Database

Email 

Queue 

Security 

Once I’ve farmed out as much functionality as I can, what’s left is typically the bespoke business logic and the glue between all the external services.

Business Logic is commonly used to enable:

Triggering messages such as email and push notifications on developer-defined changes in the data store. Optimizing the data exchange with the app by joining multiple data collections. Validating app user actions in order to enforce business rules. Providing a means to host platform-agnostic code and save development time on multi-platform apps.

To build it I always go for the low-code option because of my natural laziness (and I happen to work for one so I’m dogfooding at the same time). Two low-code tools that allows me to do pretty much anything and connect to most services, on-premise or not, are:

Skilled developers can, of course, use their favourite programming language to build the bespoke bits. Most programming languages have one or more frameworks to help reduce the boilerplate. Some of the popular ones are:

If you haven’t recently tried a low-code tool I suggest trying one for your next small project. Pick something that you want to get out of the door quickly, even better if you expect it to be mostly boilerplate. You might be surprised at how much they can improve your development speed.

Another interesting angle to try is building ‘serverless’ functions using something like AWS Lambda or Azure functions to implement the API. I’ve found that the architectural complexity eats a lot of time but if you’re already familiar with those platforms it might be an easy way to build a couple of endpoints.

The simplest thing to do is to use one of the hosting platforms that supports your programming language of choice.

Or in the low-code case the low-code platform does the hosting. Of course, these might not work for the next Facebook or Twitter API but then you’ll probably need some specialists and bespoke infrastructure anyway.

It’s amazing how far we’ve come since we hacked around in BASIC on an IBM XT with 128 KB of RAM. If you wanted a database you needed to build it yourself. If you wanted a queue you needed to build it yourself. API? What’s that?

Now APIs are everywhere. They help us integrate third-party features, connect enterprise systems, and exchange data between apps.