How a request and a response work

A request is a message from one program. A response is the answer. Every API exchange is one of each, and that's all it is.

Who asks and who answers

The program that asks is called the client. The program that answers is called the server. Your phone app can be a client. So can a spreadsheet add-on or a booking tool.

¹ MDN calls the client's messages requests and the server's answers responses. In this basic pattern, the client asks first and the server answers.

What a request holds

Think of posting a form to an office. You write what you want, say where it goes, add notes, and enclose any papers. A web request has the same pieces.

• A method. A short word such as GET or POST that says what you want done. The page on endpoints and methods covers these.
• An address. The path to the thing you're asking about.
• Headers.¹ MDN calls them "Optional headers that convey additional information for the servers." Your API key often travels in a header.
• A body. The content you're sending, if the request needs one. A request that only reads something usually has none.

What a response holds

The reply has a similar shape. It carries headers too. It may carry a body, such as the weather report or the AI model's answer. And it always starts with a status code.

¹ MDN says the status code shows "if the request was successful or not, and why." Code numbers sit in families, which the page on error codes walks through. The body is usually written in a tidy text format called JSON.

A tiny walk-through

Say a stock-checking tool asks a supplier's API how many boxes of a product are left. The tool sends a request that names the product and carries its key. The supplier's server looks it up. It sends back a response that says the request worked and gives the number.

Your tool then shows that number on screen. You never see the messages. You see the answer.

No memory between requests

¹ MDN says "HTTP is stateless", with no link between two requests carried out one after the other on the same connection. MDN adds that "HTTP cookies allow the use of stateful sessions" on top of that core.

So HTTP itself doesn't tie one request to the next. Many APIs cope by having each request carry what the server needs, including who you are, which is why an API key is often sent with every call. That's how many APIs work, not something MDN says. Check the maker's documentation to see how an AI tool handles earlier messages.

Why the answer sometimes isn't what you hoped

A request can fail for plain reasons. The address could be wrong. The key could be missing. You could have asked too often. The status code is the first clue, so read it before anything else.

Keep secrets and customer data out of an AI tool's prompt box when you're chasing a failed request, unless your business's own policy allows it. Share only the status code and the message.

The words again

• Client: the program that asks.
• Server: the program that answers.
• Call:² in Wikipedia's weather example, "The message that activates the sensor is an API call".
• Status code: the number at the start of every reply.