Apps talk to each other through APIs: agreed-upon rules for how one piece of software can ask another for information or for an action. On the web, that usually means one program sends a structured request and another sends back a structured response. Think of ordering a pizza: you don’t walk into the kitchen and cook. You use the menu, place an order the restaurant understands, and get food and a status back.
What is an API, in pizza terms?
MDN’s glossary describes an API as an interface, a contract, that lets software interact with other software. The menu is a good stand-in for that contract. It tells you what you can ask for, and the restaurant will only reliably serve orders that follow it.
As an Amazon Associate I earn from qualifying purchases.
| At the pizzeria | In software |
|---|---|
| The menu | The API’s contract: what you can ask for and in what form |
| You, the customer | The client (an app, a web page, a script) |
| Your order: “one large margherita, delivery” | The request: a method, a target, and sometimes headers and a body |
| The kitchen | The server and the code behind the API |
| “Sorry, we’re out of dough” | An error status code in the response |
| The pizza and the receipt | The response data, such as JSON, plus headers |
The point of the menu is that you never need to know how the kitchen works. You only need to know how to order.
Recommended Free Tools
Where the analogy breaks down
- Not every API is a web service. MDN’s glossary also covers APIs built into browsers and operating systems, where one piece of code calls another on the same device. No network trip is involved.
- The “kitchen” isn’t always another company. A company’s own mobile app often calls its own servers through an API.
- There is no single format. Different APIs use different data formats, rules and styles. Nothing makes them all look alike.
How does an API work? A request and a response
Many web APIs run over HTTP. MDN’s overview describes it as a client-server protocol: the client sends a request message, the server sends back a response message. Both have defined parts, and the response includes a status code.
#1 Best Overall
- The app decides what it needs. A weather app needs today’s forecast. A checkout page needs to place an order.
- It builds a request. That means a target (the endpoint, a specific address on the server), a method describing the intent (for example, fetch something versus submit something), and any required headers or body.
- The server handles it. It checks the request, does the work, and prepares a response.
- The response comes back. It carries a status code, headers, and possibly a body, often JSON.
- The app checks the result and acts on it. It shows the forecast, confirms the order, or displays an error.
A made-up example, with a hypothetical endpoint:
GET https://api.example-pizza.test/orders/1042
Response: 200 OK
{
"id": 1042,
"item": "large margherita",
"status": "out_for_delivery"
}
The status code gives the outcome at a glance. HTTP groups codes into families: 2xx generally means success, 4xx means the client’s request was a problem, and 5xx means the server failed. That is like hearing “here’s your pizza,” “that isn’t on the menu,” or “the oven broke.”
What happens when a web page asks a server for data?
In a browser, JavaScript commonly makes requests with the Fetch API, a built-in way to send requests and work with responses. fetch() returns a promise for a Response object.
Rank #2
- Used Book in Good Condition
const res = await fetch("https://api.example-pizza.test/orders/1042");
if (!res.ok) {
throw new Error("Order lookup failed: " + res.status);
}
const order = await res.json();
console.log(order.status);
The res.ok check matters. According to MDN, the promise from fetch() resolves as soon as the server’s response headers arrive, even if the status is an error like 404 or 500. It does not reject for HTTP error statuses. Skip the check and your code may treat “we’re out of dough” as a successful order.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why is my API request blocked by CORS?
If a page on one site tries to read a response from a different site, the browser steps in. Under the same-origin policy, page scripts can’t freely read responses from other origins. CORS (Cross-Origin Resource Sharing) is the header-based mechanism that lets a server say which origins are allowed. An origin is the combination of scheme, host and port, so https://shop.example and https://api.example are different origins.
Rank #3
In pizza terms, the restaurant is willing to cook, but the doorman (the browser) only hands the food to people the restaurant has named in advance.
What this means in practice
- The server decides. It grants access by sending suitable CORS headers in its response. Fixing a CORS error normally means configuring the server, not changing your front-end code.
- The request may still arrive. The server can receive and process a request while the browser refuses to let your script read the response. A CORS error doesn’t prove the server never got it.
- Some requests get a preflight. For certain methods or headers, the browser first sends an
OPTIONSrequest to ask whether the real request is permitted. If the server’s answer doesn’t allow it, the real request isn’t sent. - Credentials are stricter. For requests that include cookies or similar credentials, MDN notes the server must explicitly name the requesting origin and allow credentials. A wildcard
*origin isn’t enough.
CORS is not a login system, and it doesn’t protect a server from non-browser clients. Disabling browser security to make an error vanish only hides the problem on your own machine. Your users’ browsers will still enforce the rules.
Rank #4
API, HTTP, JSON, Fetch, CORS and OpenAPI: who does what?
These terms get blended together, but each has its own role.
| Term | Role | Pizza version |
|---|---|---|
| API | The interface or contract for software-to-software interaction | The menu and ordering rules |
| HTTP | A common protocol that carries web requests and responses | The phone line or delivery route |
| Endpoint | A specific target address for a request | One menu item’s order line |
| JSON | One common way to represent data in a message | How the order slip is written |
| Fetch | A browser JavaScript API for making requests | The customer’s phone |
| CORS | Browser-enforced permission for cross-origin reads | The doorman’s guest list |
| OpenAPI | A language-agnostic format for describing HTTP APIs | The printed menu itself, documented in a standard layout |
The OpenAPI Specification (version 3.0.4 is dated 24 October 2024) describes an HTTP API’s interface so people and tools can understand it. It is documentation, not the live channel that sends requests. REST, which you’ll often hear in the same breath, is an architectural style for designing web APIs. It is a separate idea from HTTP, JSON and OpenAPI, and an API doesn’t have to be “REST” to be an API.
Best Value
Why would an app need an API at all?
- Reuse. A maps or payment service can offer its features to thousands of apps without each rebuilding them.
- Separation. A phone app and a website can share one back end, as long as both follow the same contract.
- Safety and stability. The provider exposes only what it chooses, and can change its internals without breaking callers, as long as the contract holds.
Where to practice
Start with MDN’s pages on APIs, HTTP, Fetch and CORS for concepts. For hands-on work, an API client lets you send requests and inspect status codes and headers without writing code. Postman’s “Learn APIs” page lists free documentation, courses, videos and browser-based tools. Its book The API-First Transformation is aimed at API strategy, technology choices and operations, so it is leadership-level reading rather than a beginner’s guide to making a first request.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.




