IT Literacy for Non-Developers #2: What Is an API? — The Promise That Lets Services Talk to Each Other

IT Knowledge
6 min read

In the last post, I said that a website is made of three layers - frontend, backend, and database - and that these three layers constantly talk to one another with every user action. I also left one thing for later: what agreement makes that conversation possible. That agreement is the API.

API is a word developers use several times a day. You’ve probably heard things like “we pull that data through an API,” “the API isn’t responding,” or “that feature needs an external API integration, so it’ll take some time.” In this post, we’ll look at what an API really is, and why modern services barely run without one.

This series, IT Literacy for Non-Developers, consists of five parts.

  • #1 What Is a Website Made Of? — Frontend, Backend, and Database
  • #2 What Is an API? — The Promise That Lets Services Talk to Each Other ← this post
  • #3 Servers, the Cloud, and Deployment
  • #4 Bugs, Hotfixes, and Rollbacks — How Developers Respond to Incidents
  • #5 Git and Version Control — How Many People Edit One Codebase

An API Is a Promise to Exchange Data in a Fixed Way #

In the last post, I compared the backend to a restaurant’s kitchen. The guest doesn’t walk straight into the kitchen. They look at the menu, place an order with the staff in a fixed way, and the food comes out in a fixed form. The guest doesn’t need to know how the kitchen works. As long as they use the menu and the staff as intended, they can get what they want.

The API is exactly this menu and this staff. It’s the promise that “if you request it this way, you’ll get a response in this format,” and it’s the channel through which data is exchanged according to that promise. Even though the frontend doesn’t know the backend’s inner workings, it can still get the data it wants by making a request through the fixed channel called an API.

API stands for Application Programming Interface. The phrase sounds difficult, but unpacked, it means a channel through which programs exchange data in a fixed way. Just as a person communicates with the kitchen through the menu, a program communicates with another program through an API.

It Works Through Requests and Responses #

A conversation through an API happens in two steps: a request and a response.

Let’s take a weather app as an example. The app screen (the frontend) sends a request to the backend asking “tell me the current weather in Seoul.” This request carries both what it wants and the information needed to answer it (which city). The backend receives that request, finds the data, and then responds in the agreed format. For example, something like “city is Seoul, temperature is 21 degrees, condition is clear.”

What matters here is that the response doesn’t come in some arbitrary shape - it comes in a format agreed on in advance. In development, the format most often used is JSON. You can think of it as a form organized so that even a person reading it can tell “this name has this value.” Because the format is agreed on, the frontend only has to pull the temperature value out of the response it received and show it on the screen.

It’s Used Inside, and Pulled in From Outside #

An API isn’t used only within a single service. We can broadly divide it into two kinds.

The first is the internal API. It’s the channel through which a single service’s frontend and backend exchange data. The login process we saw in the last post falls under this.

The second is the external API. It’s about pulling in functionality another company has built through a channel called an API. The apps we use every day are full of these external APIs. The feature that displays a map on the screen is usually powered by a map API, payment uses the API of a payment processor, and the feature that lets you log in easily with Kakao or Google integrates a login API that company provides. Features like sending text messages, looking up exchange rates, and translation work the same way.

Thanks to this, there’s no need to build every feature yourself. You slot in well-built external functionality through an API and complete a service quickly. Apps these days are closer to products assembled from several APIs.

Why Knowing This Makes a Non-Developer’s Job Easier #

Understanding APIs makes conversations with developers much smoother in practice.

  • You can gauge the weight of a feature request. A request like “put a map here” is a job that requires integrating a map API, and it costs that much time and money. Once you can tell whether something is attaching new external functionality or just showing data that already exists, you develop a feel for timing.
  • You can narrow down where a problem is. In situations like “the map isn’t showing” or “payment stopped,” you can suspect together whether it’s a problem in our own service or in an external API we integrated.
  • You can ask good questions at the planning stage. A single question like “is there a ready-made API for this feature, or do we have to build it ourselves?” can change the schedule and the cost significantly.

In particular, most external APIs are charged based on usage. As users grow and calls increase, the cost grows accordingly. Knowing this lets you estimate the cost structure in advance as the service grows.

APIs Have Rules and Limits Too #

An API isn’t a channel that just anyone can use however they like. A few rules come attached.

First, there’s authentication. An external API usually issues an API key, a kind of access pass. This key verifies your identity and lets only permitted users use the channel.

Next, there’s the call limit. It’s commonly called a rate limit, and it restricts you to a fixed number of requests within a given period of time. Once you exceed this limit, your requests are blocked for a while. It’s a mechanism that keeps one service’s surge from breaking things for other users too.

Last, there’s the risk that comes with dependency. Leaning on an external API also means following that provider’s policies. If the provider changes the response format, raises the price, or shuts the service down, you feel the impact directly. It’s worth remembering that behind the convenience lies this kind of dependency.

Wrap-Up #

In this post, we looked at what an API is.

  • An API is a promise - and a channel - through which programs request data in a fixed way and receive responses in a fixed format.
  • The conversation happens through requests and responses, and the response usually comes in an agreed format like JSON.
  • There’s the internal API that connects the parts inside a single service, and the external API that pulls in someone else’s functionality.
  • APIs come with rules and limits like authentication, call limits, and dependency risk.

The backend we saw in the last post, and the API we saw in this one, both run in places the user never sees. So where do this backend and API actually run? In the next post, we’ll look at what servers, the cloud, and deployment are.

X