What Is a Web API?

Have you heard of APIs?

 

If you’ve recently started using AI to write code, or you want to connect two tools, you’ve probably come across the term.

 

Someone might tell you to sign up for an API. Someone else might say that a service doesn’t make an API available, so you can’t connect to it directly.

 

So what exactly is an API? And why does it sometimes have “Web” in front of it?

 

Let’s start by breaking down the name.

 

API stands for Application Programming Interface, usually translated into Chinese as「應用程式介面」. This is also the concept covered in MDN’s explanation of APIs.

 

First, Application.

 

An app on your phone, software on your computer, or a small program that helps you organize files can all be applications.

 

It doesn’t have to be anything big. An application doesn’t need a screen with buttons.

 

For now, imagine two programs.

 

One is already written and has a feature you want to use. The other is the program you’re writing, and you want to ask the first program to do something for you.

 

For example, suppose a program can already look up the weather by city. You’re building a small tool, and you want to use its weather lookup feature.

 

But how do you ask it to do something?

 

That brings us to Programming and Interface.

 

Programming usually means writing code. Here, you can think of it as using code to call a feature that’s already been written in another program and have it run.

 

You’re not rewriting the other program, and you’re not operating its screen yourself.

 

Instead, the program you write can ask the existing program to do something.

 

With the weather tool we just mentioned, your program passes along the city you want to look up. The other program runs the lookup and returns the result.

 

So what do you go through to ask it to do that?

 

The Interface.

 

When people hear “interface,” they often picture a login page, a shopping cart, or buttons they can tap on a phone.

 

Those are interfaces for people to use.

 

But here, another program is going to use the feature. It doesn’t necessarily need to see a screen or click buttons with a mouse.

 

What it needs is an entry point designed for programs.

 

That’s the kind of interface an API is.

 

Through this interface, you can use the features the other program makes available without first understanding how its code is written.

 

It’s like using a mouse. You don’t need to know how the parts inside it work. You just use the controls it provides.

 

The interface itself does limit how you can operate it, though.

 

Take a mouse with just a left and a right button. You can click either button, but you can’t type English letters directly on the mouse.

 

To type text, you would use a keyboard. A keyboard gives you a different set of controls from a mouse.

 

The same goes for a program’s interface.

 

Just because a program offers a weather lookup feature doesn’t mean you can use that same interface to ask it to organize the files on your computer.

 

If it asks you to provide a city, you need to provide one in a form it accepts. You can’t give it nothing and expect it to know which place you want to look up.

 

Which features you can use, what you need to provide, and what results you’ll get back are all things you need to know when using the interface.

 

So first, get clear on which way this works.

 

One program provides features, and another program calls those features through its interface.

 

By “which way,” I mean who provides the features and who uses them. Data can still be sent back after a lookup.

 

Connecting two programs also doesn’t mean they can operate all of each other’s features. If the other side is going to make features available for you to use as well, it needs an interface you can use, too.

 

So what changes when you add “Web” to the name?

 

An API doesn’t necessarily need a network connection.

 

You could write a program that uses an API provided by your operating system to read files, and do all of that on your own computer.

 

The Web API we’re talking about in this article makes this kind of interface for programs available through the Web.

 

Your program and the other program don’t need to be on the same computer. Your program can send a request to use a feature over the network, then receive the result once the other program has processed it.

 

For more on how sending requests and receiving responses works, see MDN’s explanation of HTTP.

 

Let’s keep going with our hypothetical weather tool.

 

You want to build a small tool that lets users choose a city and see the weather.

 

But you don’t have your own weather station or weather data.

 

You can find a service that provides weather data and makes a Web API available.

 

Once the user chooses a city, your program sends that city through the interface the service provides.

 

The service runs its existing lookup feature and sends the weather data back. Once your program receives it, it can arrange that data into a display users can understand.

 

Here, you’re building your own small tool while using a feature another program already provides.

 

You don’t need to build a whole weather lookup service yourself, but you do need to check what the service makes available and how to use it.

 

If you want AI to help you connect the two, you can explain the requirements clearly: “I want users to be able to choose a city, look up the weather through this service’s API, and display the results. Please implement this according to its documentation.”

 

If you’ve connected them but aren’t getting a result, start by checking what your program sent and what the other program returned. Did you provide a city? Did you provide it in the right way? Did the service return weather data, or a reason the lookup failed?