HTTP Explained for Beginners — The Protocol Behind Every Web API

What You'll Learn

• What HTTP is and why it is the language of web APIs
• The structure of an HTTP request and an HTTP response
• How a real HTTP exchange looks on the wire
• The difference between HTTP and HTTPS

Why This Matters

Almost every web API in the world uses HTTP. If you cannot read an HTTP exchange, you cannot debug an API call, write a test, or build an automation. This lesson gives you the protocol in one sitting — small enough to understand, complete enough to use.

Simple Explanation

HTTP (HyperText Transfer Protocol) is a set of rules for how two computers should exchange messages over a network. It is a request-response protocol: one side sends a request, the other side sends a response, and both messages follow a specific format.

That is it. HTTP is just an agreement about the format of those two messages. It does not care what the messages contain — they could be HTML pages, JSON data, images, or plain text. The format is the same.

Real-World Analogy — Sending a Letter

HTTP works like a formal letter:

• The envelope has the destination address and a return address.
• Inside is the actual letter — the message you want to deliver.
• The recipient opens it, reads it, and writes back with their own envelope and letter.

In HTTP, the "envelope" is the request line + headers, and the "letter inside" is the body. The response follows the same structure.

The Anatomy of an HTTP Request

Every HTTP request has four parts:

1. The request line

Tells the server what the client wants:

GET /v1/forecast?latitude=19.07&longitude=72.87 HTTP/1.1

This says: "I want to GET the resource at the path /v1/forecast with these query parameters, using HTTP version 1.1."

2. Headers

Key-value pairs that add metadata about the request:

Host: api.open-meteo.com
User-Agent: curl/7.81.0
Accept: application/json

Headers tell the server things like: which host the request is for, what client is sending it, and what format the client wants the response in.

3. A blank line

A single empty line that tells the server "headers are done, what follows is the body."

4. The body (optional)

For GET requests, the body is usually empty. For POST and PUT requests, the body contains the data being sent:

{"name": "Anita", "email": "anita@example.com"}

A Complete HTTP Request

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...

{"name": "Anita", "email": "anita@example.com"}

Read it line by line:

• POST /users HTTP/1.1 — method POST, path /users, HTTP version 1.1.
• Host: api.example.com — the server to deliver this request to.
• Content-Type: application/json — the body is JSON.
• Accept: application/json — the client wants the response in JSON.
• Authorization: Bearer ... — the client's access token for authentication.
• Blank line.
• The JSON body — the actual data being sent.

The Anatomy of an HTTP Response

A response has the same four parts, slightly rearranged:

1. The status line

HTTP/1.1 201 Created

Tells the client: HTTP version, status code (201), and a short reason phrase ("Created").

2. Headers

Content-Type: application/json
Content-Length: 47
Date: Sat, 23 Aug 2026 09:14:32 GMT

3. A blank line

4. The body

{"id": 123, "name": "Anita", "email": "anita@example.com"}

A Complete HTTP Response

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 62
Location: https://api.example.com/users/123

{"id": 123, "name": "Anita", "email": "anita@example.com"}

The Full Exchange

Client                                          Server
  |                                               |
  | --- POST /users HTTP/1.1 -------------------> |
  |     Host: api.example.com                     |
  |     Content-Type: application/json            |
  |     Authorization: Bearer eyJ...              |
  |                                               |
  |     {"name":"Anita","email":"anita@x.com"}    |
  |                                               |
  |                                               | (validate, create user)
  |                                               |
  | <--- HTTP/1.1 201 Created ------------------ |
  |      Content-Type: application/json           |
  |      Location: /users/123                     |
  |                                               |
  |      {"id":123,"name":"Anita",...}            |
  |                                               |
  | (parse JSON, use response)                    |

HTTP vs HTTPS

HTTPS is HTTP with an extra layer of encryption (TLS). The format of requests and responses is identical — only the transport is encrypted so no one between the client and server can read the contents.

Modern APIs almost always use HTTPS. Plain HTTP is acceptable only for local development (http://localhost); never use it for production traffic or anything that involves authentication.

Common Mistakes

1. Confusing HTTP with HTML. HTML is a content format for web pages. HTTP is the protocol that carries those pages (and JSON, and images, and everything else).
2. Forgetting the blank line between headers and body. If you ever write a raw HTTP request by hand, the blank line is mandatory. Without it, the server will keep waiting for more headers.
3. Treating HTTP as synchronous and reliable. HTTP requests can fail, time out, or arrive out of order. Good clients handle all three.
4. Using HTTP for production traffic. Use HTTPS always. Plain HTTP exposes everything you send — including passwords and tokens.

Practical Exercise (10 minutes)

Open a terminal and run this cURL command (cURL is pre-installed on macOS and Linux; on Windows use PowerShell or install cURL):

curl -v https://api.open-meteo.com/v1/forecast?latitude=19.07&longitude=72.87&current=temperature_2m

The -v flag tells cURL to print the full HTTP exchange. Look at the output:

1. Find the request line (> GET /v1/forecast...).
2. Find the request headers (lines starting with >).
3. Find the response status line (< HTTP/... 200).
4. Find the response headers (lines starting with <).
5. Find the response body (the JSON at the end).

You have just seen a real HTTP exchange end to end.

Mini Challenge

Using the cURL output above, identify the value of each of these headers in the response: Content-Type, Date, Content-Length. What does each one tell the client?

Key Takeaways