If you are new to tech, you might be confused by a term that you’ll see all over the place: API. Let’s take a look at what it means, some examples, and how you can use it.
API is the abbreviation for application programming interface. Those words alone probably don't help much, so let’s see what each of them means here.
Applications are programs that provide some feature(s) to users. They store and retrieve data, perform calculations, etc. Applications give us a reason to use computers at all. The direct usefulness of applications contrasts with programs that we run to access other programs, for example:
- we use the operating system to open applications, and
- we use browsers to access web applications.
The interface is an exposed part of an application, prepared to receive input from the outside. As a user, you maybe already be familiar with some types of interfaces:
- graphical user interface (GUI)—the most common interface that we all know from personal computers and mobile devices.
- command line interface (CLI)—where the user types a program name and parameters to run a program.
An API is an interface that is meant to be used by other programs. So, instead of exposing buttons or menus, the application provides a way of interacting with it in a machine-friendly way. Nowadays, it is typically understood as a Web API—an online server that exposes different routes and returns data in a format that is both easy to parse for a computer and understandable for humans.
APIs are simply a way for applications to communicate with each other. Good APIs are stable—because a breaking change in one application will require an update in all applications that use it. And good APIs are documented—because otherwise it’s very difficult to write a program that uses them.
Let’s take a look at some examples of APIs that you could play around with.
The URL (uniform resource locator) is a form of an API. As users, we usually use them without thinking much about them. We use a web browser to fetch and display a website from an address that we clicked as a link. With well-designed addresses, we can tweak them and get still get a response from the server:
- when we replace the
Netherlandspart of https://en.wikipedia.org/wiki/Netherlands with
Belgium, we get a valid URL: https://en.wikipedia.org/wiki/Belgium
A well-designed URL system invites us to tweak the address but will not help much if we ask for a page it doesn’t have. For example, when we replace
TypeScript, we get https://developer.mozilla.org/en-US/docs/Web/TypeScript:
Playing around with URLs can be a simple way of trying out communicating directly with a machine—and getting used to their requirements of providing the parameters in exactly the way they expect.
Another simple way of starting with APIs are command line programs. Similarly to web APIs, the first step is to read the documentation. Then, make a few trial and error attempts at getting the program to do what you want it to do. In another article, I provide a simple introduction to CLI programs.
As a tester or a programmer, you are most likely to use a web API. They are relatively easy to use, but there are some difficulties involved:
- the access can be limited to authorized users—each system will have a different way of authorization and can require creating a user, logging in, providing the session information in cookies or some ID and key pair
Let’s see some examples of APIs that you could experiment with:
The main use of an API is to call other applications from the program you write. You can use them to leverage other systems for any variety of functionalities:
- OAuth for authorization with 3rd-party providers such as Google for Facebook
- getting automated translations from the cloud
- getting geolocation from map systems
- automatically cross-publishing the same content on many social media platforms
- accessing large language models to provide some AI functionality
- and many more
In a way, a lot of modern programming is writing glue code between different APIs.
Because so much programming is about calling APIs, there is a lot of troubleshooting that can be done there. Many bugs I
created encountered in my frontend programming career were caused by either
- sending an incorrect request to the API, or
- interpreting the response incorrectly.
If the frontend sends a valid request and displays the response as it should, then the bug is probably on the backend. If you can troubleshoot that much as a tester, this can significantly speed up finding and fixing the bug.
If you are interested in learning more about APIs, programming, and testing, sign up here for an occasional email from me.