APIs

APIs, or Application Programming Interfaces, are a way for two unrelated applications to talk to each other. Just like databases, they're an essential part of backend development.

You can picture an API like a two-way tunnel that connects a pair of applications. A developer can send requests through this tunnel and receive responses in the opposite direction. For example, they might send a request to a weather website, and receive the latest forecasts. They could display those forecasts on a travel app they're building, instead of taking the time to build their own weather prediction system from scratch.

There are lots of types of API. Web APIs, for instance, allow the interaction between applications over the web, while Database APIs enable communication between an application and a database.

HTTP, or Hypertext Transfer Protocol, is a set of standards which takes care of any data exchange on the web. Understanding these standards is central to understanding APIs.

HTTP relies on methods, also known as verbs. These are simple commands that define what type of action a client wants to perform on a resource. HTTP methods are universally recognized by web servers and clients, which is why they’re so useful, like a common language that every single web application speaks.

Some of the most common HTTP methods are GET, POST, PUT, and DELETE.

GET retrieves data, POST sends new data, PUT updates existing data, and DELETE removes data.

RESTful APIs are a common type of API. They were first pioneered by Roy Fielding – an influential computer scientist – in 2000.

The 'REST' stands for Representational State Transfer, which is a set of conventions that guide API design. The main difference between regular APIs, and the RESTful variety, is that a 'normal' API doesn't necessarily follow specific architectural guidelines, whereas every single RESTful API is standardized to REST principles.

Fielding's work has become a cornerstone in the field of backend development, with RESTful APIs being widely adopted due to their scalability and accessibility.

RESTful architecture has several constraints, which help to make sure that RESTful APIs are consistent and scalable.

For example, the client making the API request, and the server receiving the API request, must be separate entities. This request must also be stateless, which means the server doesn't need to store any information when it receives the client's request.

There also needs to be a uniform interface – this means a standardized approach to communication, no matter what type of client and server are trying to interact. A key part of this is using HTTP methods to create, read, update, and delete data. These methods, also known as CRUD operations, form the basis of any interactive application.

APIs rely on something called endpoints. If the API itself is a tunnel, then the endpoints are doors on the side of an application that this tunnel is able to link to.

In more literal terms, endpoints are URLs – or Uniform Resource Locators – which function as touchpoints for other applications to access. For example, a government website might have an endpoint called /public-holidays. If a backend developer built a calendar app, they could send a request to /public-holidays, retrieve that data, then display it on their app.

Often, a developer will share documentation that lets other people know how to find their application's endpoints.

A Backend Developer might find themselves accessing other people's endpoints – but they'll also find themselves designing endpoints of their own.

To implement API endpoints, they will need to write code that tells the server how it needs to react when it receives various requests. For example, for a GET request to an endpoint, a developer would write the logic that fetches data from a database or another source, and prepares the data for the response.

Each API endpoint should have a specific URL path, for example /tasks. Other people will run into a 404 error if their client sends a request to a path that does not exist.

The ideal API is high quality, performs under high load, and is easy to maintain.

Best practices to develop such APIs include using RESTful principles. It’s also a good idea to design intuitive endpoints, which makes the API easy to understand even for people who didn’t develop it. For example, imagine you are looking at an endpoint that reads like:

GET /api/v1/xyp987

By contrast, check out this endpoint:

GET /api/v1/products

The second one is much more clear.

It’s critical for a developer to test their endpoints, and make sure the response is correct.

API testing should cover functionality, performance, security, and error conditions. Functionality testing checks that the API works as expected, performance testing checks how the API performs under load, security testing checks for vulnerabilities, and error condition testing checks how the API handles errors.

This can be done automatically using testing frameworks, or manually using tools like Postman. Manual testing involves sending requests to the API endpoints and checking the responses by hand.

Luckily for developers, it’s no longer necessary to write all their APIs from scratch. Many languages have frameworks that provide a structured way to develop APIs, offering pre-built functions and libraries.

Choosing a framework for API development depends on factors such as the programming language, the complexity of the project, and the team's familiarity with the framework.

For example, if a project requires complex functionality and scalability, a developer might opt for a more robust and feature-rich framework like Ruby on Rails, Django REST framework, or ASP.NET Core.