What Are APIs?

The weather app that doesn't own a single thermometer

Open any weather app on your phone. It shows you the temperature, humidity, wind speed, and a 10-day forecast for your exact location. But the company that built that app doesn't own a single weather station. They don't launch satellites. They don't employ meteorologists.

Instead, the app sends a request to the National Weather Service (or a provider like OpenWeatherMap) saying: "Give me the current weather for latitude 40.7128, longitude -74.0060." A few milliseconds later, it gets back structured data — temperature, conditions, forecast — and displays it in a pretty interface.

That request? It went through an API.

Your weather app is essentially a good-looking middleman that asks other computers for data and shows it to you. And nearly every app on your phone works the same way: Uber asks Google Maps for directions via an API. Instagram sends your photo to a cloud storage API. DoorDash checks restaurant availability through restaurant system APIs.

APIs are the invisible wiring behind every modern application.

What an API actually is

API stands for Application Programming Interface. In plain English: it's a menu for software.

Think of a restaurant. You (the customer) don't walk into the kitchen and cook your own food. Instead, the restaurant gives you a menu — a list of things you can order, with descriptions and prices. You tell the waiter what you want, the kitchen makes it, and the waiter brings it back.

An API defines what you can ask for, how to ask for it, and what you'll get back. It hides the complexity behind a simple interface — just like you don't need to know how to cook to order from a restaurant.

How API requests work

A typical web API conversation looks like this:

Here's what an actual API request and response looks like:

Request:

GET https://api.openweathermap.org/data/2.5/weather?q=London&appid=YOUR_KEY

Response (JSON):

{
  "name": "London",
  "main": {
    "temp": 285.15,
    "humidity": 72
  },
  "weather": [{ "description": "light rain" }]
}

That's it. The app asked a question, got structured data back, and can now display "London: 12C, light rain, 72% humidity" in any design it wants.

There Are No Dumb Questions

What is JSON?

JSON (JavaScript Object Notation) is the most common format for API data. It's human-readable text that structures data as key-value pairs. Think of it as a standardized way for computers to exchange information. Almost every API you'll encounter uses JSON.

What does "endpoint" mean?

An endpoint is a specific URL that an API makes available — like a specific item on the restaurant menu. /weather might be one endpoint, /forecast another. Each endpoint serves different data or performs a different action.

HTTP methods: the verbs of APIs

Just like human language has verbs (get, create, update, delete), HTTP has methods that tell the API what action you want to perform:

Most APIs you interact with use these five methods. GET and POST account for the vast majority of API traffic.

REST vs GraphQL: two approaches to APIs

The two most popular styles for building web APIs are REST and GraphQL:

REST (Representational State Transfer)

REST is the most common API style. Each resource (users, products, orders) has its own URL, and you use HTTP methods to interact with it.

GET    /api/users/123        → Get user 123
POST   /api/users            → Create a new user
PATCH  /api/users/123        → Update user 123
DELETE /api/users/123        → Delete user 123

REST is simple, widely understood, and works great for most use cases. Its downside: you might need multiple requests to assemble a single page of data. A profile page might require one call for user data, another for their posts, and another for their followers.

GraphQL

GraphQL (created by Facebook in 2015) lets you ask for exactly the data you need in a single request. Instead of hitting multiple endpoints, you send one query that specifies the exact fields you want.

query {
  user(id: 123) {
    name
    email
    posts { title, date }
    followers { name }
  }
}

One request. All the data. No over-fetching (getting fields you don't need) and no under-fetching (needing multiple requests).

There Are No Dumb Questions

Which is better — REST or GraphQL?

Neither is universally better. REST is simpler and works well when resources map cleanly to URLs. GraphQL shines when a client needs flexibility — like a mobile app that needs less data than a desktop app from the same backend. Many companies use both: REST for simple services, GraphQL for complex frontends.

Do I need to know how to build APIs to work in tech?

Not necessarily. But understanding how they work is essential. Product managers define API requirements. Designers need to know what data is available. Marketers use APIs for integrations. API literacy is a cross-functional skill.

API keys and authentication

Most APIs don't let just anyone make requests. You need to prove who you are. The most common methods:

Webhooks: APIs in reverse

Normal APIs follow a pull model: your app asks the server for data whenever it wants. But what about events you can't predict — like a customer completing a payment?

Webhooks flip the model. Instead of your app constantly asking "Has anything happened yet? Has anything happened yet?" (called polling), the server proactively sends your app a notification when something happens.

Real-world webhook examples:

• Stripe sends your server a webhook when a payment succeeds or fails
• GitHub sends a webhook when code is pushed to a repository
• Slack sends a webhook when a user posts in a channel
• Shopify sends a webhook when a new order is placed

APIs you use without knowing it

Every time you do any of these things, APIs are working behind the scenes:

There Are No Dumb Questions

What is a "public API" vs a "private API"?

A public API is available for anyone (or any approved developer) to use — like the OpenWeatherMap API or the Twitter/X API. A private API is internal, used only within a company. Most companies have far more private APIs than public ones — connecting their own microservices behind the scenes.

What does "rate limiting" mean?

To prevent abuse, most APIs limit how many requests you can make per minute or per day. For example, Twitter's free API tier allows about 1,500 tweets read per month. If you exceed the limit, you get a 429 (Too Many Requests) error until the window resets.

Back to the weather app

That weather app on your phone — the one that doesn't own a thermometer — works because of APIs. It sends a structured request to a weather data provider, receives JSON back, and renders it beautifully. The app is a thin layer of design on top of an API call. And that pattern — a clean interface consuming structured data from a remote service — is how virtually all modern software is built. Understanding APIs is understanding how the digital world is wired together.

Key takeaways

• An API is a structured interface that lets one piece of software request data or actions from another — like a restaurant menu for code
• HTTP methods (GET, POST, PUT, PATCH, DELETE) define what action an API request performs
• REST is the most common API style — one URL per resource, simple and predictable
• GraphQL lets clients request exactly the data they need in a single query — powerful for complex applications
• Authentication (API keys, OAuth, JWT) controls who can access an API and what they can do
• Webhooks are APIs in reverse — the server pushes notifications to your app when events occur, instead of your app constantly polling
• APIs are the glue connecting modern software: 83% of internet traffic is API calls (Cloudflare, 2024)