This is the start of a series where I learn backend concepts step by step and write them down.

I don’t want to just “use” APIs, I want to see what’s really going on when a client and server talk to each other.
Before I touch databases or frameworks, I need to understand the basics: requests, responses, headers, status codes, tools like Postman and curl.

This first post is that groundwork. Think of it as the “ingredients check” before we start building APIs.

Client–Server and How HTTP Makes It Work

When we talk about APIs, we’re really talking about how clients and servers communicate.

• Client → anything that sends a request (browser, Postman, curl).

• Server → anything that listens for requests and sends responses (Node.js server, public API, etc.).

Every action — fetching a webpage, hitting an API, sending data — follows this pattern:

Client  --->  Request  --->  Server
Client  <---  Response <---  Server

Why HTTP?

APIs work over HTTP (Hypertext Transfer Protocol) — the “language” clients and servers use to talk to each other.

Without HTTP:

• Clients wouldn’t know how to format requests.

• Servers wouldn’t know how to interpret them.

HTTP gives structure to every message:

1. Request line → what the client wants (method + path + version)

2. Headers → extra information about the client, format, auth, versioning

3. Body → optional data being sent (for POST/PUT/PATCH)

The server responds similarly:

1. Status line → did it succeed or fail?

2. Headers → info about the response (format, caching, encoding)

3. Body → the data itself

💡 HTTP is the protocol that enforces this structure. Every API you interact with, whether a joke API or Twitter’s API, follows these rules.

Anatomy of an HTTP Request and Response (Hands-On with a Joke API)

Enough theory — let’s see it live. Open your terminal or PowerShell and run:

curl -v https://official-joke-api.appspot.com/random_joke

-v stands for verbose — it shows the full request and response, including headers, status codes, and the body.

what actually happens behind the scenes is that curl builds a full HTTP request for you. The first line of that request — the request line — looks like this:

GET /random_joke HTTP/1.1

Here’s how curl translates your simple command:

💡 So your one-liner curl command becomes a structured HTTP request that the server can understand.

Common HTTP Methods

HTTP defines several methods to indicate what kind of operation the client wants to perform. Here’s a quick rundown:

HTTP Request Headers — The Invisible Instructions

When you make an HTTP request, whether via curl, Postman, or a browser, your request isn’t just a method and a URL. It carries headers, which are like little instructions telling the server “here’s who I am, what I want, and how to handle me.”

For example, when you ran:

curl -v https://official-joke-api.appspot.com/random_joke

you probably saw lines like:

Host: official-joke-api.appspot.com
User-Agent: curl/7.88.1
Accept: */*

• Host is mandatory for HTTP/1.1. It tells the server which domain you’re hitting — super important if the server hosts multiple sites.

• User-Agent identifies your client. Curl, Postman, and browsers all leave a signature here. Some servers even respond differently depending on who’s asking.

• Accept is a polite request saying, “I can handle JSON, HTML, or whatever you send.” Curl defaults to */* (anything goes).

Most of these headers are added automatically. You don’t have to type them, but sometimes you want to control the headers yourself.

• API Version: (Accept-Version: v1)
  Lets you specify which version of the API you want. Great for evolving the backend without breaking older clients.

• Authorization: (Authorization: Bearer <token>)
  Used for protected endpoints. Tells the server you’re authenticated. Works with JWTs, API keys, or OAuth tokens.

• Content-Type: (Content-Type: application/json)
  Specifies the format of the request body for POST or PUT requests. Curl/Postman automatically sets Content-Length (size of the body in bytes).

• Accept-Encoding: (Accept-Encoding: gzip, deflate, br)
  Tells the server which compression formats you support. Saves bandwidth and speeds up responses.

• Cookie: (Cookie: sessionId=abc123)
  Maintains session information between requests.

• Caching Headers: (If-None-Match: "etag-value", If-Modified-Since: Wed, 17 Sep 2025 00:00:00 GMT)
  Lets the server respond with 304 Not Modified if the resource hasn’t changed — caching magic.

• Custom Headers: (X-Request-ID: 123e4567-e89b-12d3-a456-426614174000)
  Track requests for debugging or logging. Many custom headers start with X- by convention.

💡 Key idea: Headers don’t carry the main data — that’s the body — but they guide the server. They’re like polite instructions attached to your request, telling the server exactly how to handle it.

The Request Body — The Meat of Your Request

Headers tell the server how to handle your request, but the body is where the actual data lives. Think of it as the main message you’re sending, for methods like POST, PUT, or PATCH.

For a simple GET request like our joke API, there’s usually no body — the request line, headers, and optional query parameters are enough. But when you want to send data to the server, that’s when the body comes in.

What Happens When the Server Responds

When you sent your joke API request, you probably got something like this in PowerShell:

VERBOSE: GET with 0-byte payload
VERBOSE: received 148-byte response of content type application/json; charset=utf-8

StatusCode        : 200
StatusDescription : OK
Content           : {"type":"programming","setup":"There are 10 types of people in this world...","punchline":"Those who understand binary and those who don't","id":28}
RawContent        : HTTP/1.1 200 OK
                    vary: Accept-Encoding
                    access-control-allow-origin: *
                    x-cloud-trace-context: 7fc1d0a29f554fa21ca36d8e2d363e83
                    Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
                    Content-Length...
Forms             : {}
Headers           : {[vary, Accept-Encoding], [access-control-allow-origin, *], [x-cloud-trace-context, 7fc1d0a29f554fa21ca36d8e2d363e83], [Alt-Svc, h3=":443"; ma=2592000,h3-29=":443"; ma=2592000]...}
Images            : {}
InputFields       : {}
Links             : {}
ParsedHtml        : mshtml.HTMLDocumentClass
RawContentLength  : 148

At first glance, it’s a lot of info, but let’s break it down so it makes sense.

1. Status Code & Description

StatusCode        : 200
StatusDescription : OK

• 200 is the HTTP status code, meaning your request was successful.

• OK is a human-readable description.

Always check the status code first — it tells you if your request worked before eve

Some common status codes you’ll see when working with APIs:

• 200 OK → everything went well (GET, PUT).

• 201 Created → something was successfully created (POST).

• 204 No Content → action succeeded, but no body returned (DELETE).

• 400 Bad Request → something was wrong with your request.

• 404 Not Found → the requested resource doesn’t exist.

• 413 Payload Too Large → your body was too big.

• 415 Unsupported Media Type → your Content-Type isn’t supported.

• 500 Internal Server Error → server failed to handle the request.n looking at the content.

2. Content - Response Body

The body contains the actual data you requested:

{
  "type": "programming",
  "setup": "There are 10 types of people in this world...",
  "punchline": "Those who understand binary and those who don't",
  "id": 28
}

• This is where the joke lives!

• GET requests usually return the resource.

• POST or PUT might return the newly created resource.

• DELETE often returns nothing (204 No Content).

💡 Pro tip: The client parses the body based on Content-Type. JSON means parse as JSON, HTML means render HTML, etc. Mismatched types can break your app.

3. RawContent

RawContent        : HTTP/1.1 200 OK
                    vary: Accept-Encoding
                    access-control-allow-origin: *
                    x-cloud-trace-context: 7fc1d0a29f554fa21ca36d8e2d363e83
                    Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
                    Content-Length...

• This shows the full raw HTTP response, exactly what the server sent over the network.

• Includes the status line (HTTP/1.1 200 OK), all the response headers, and the body.

4. Headers

Just like requests, responses have headers too. They carry metadata about the response, such as format, caching, and cookies:

for example

Content-Type: application/json; charset=utf-8
Date: Tue, 17 Sep 2025 06:10:00 GMT
Cache-Control: no-cache

• Content-Type → tells the client how to parse the body (JSON, HTML, text).

• Date → when the server processed the request.

• Cache-Control → caching instructions.

Postman is a free, beginner-friendly tool to send HTTP requests, inspect responses, and organize APIs. It makes testing APIs way easier than typing curl commands in the terminal and you can see everything in a clean, visual interface, so check it out.

The best way to really understand APIs is to play with them yourself.

Here’s a list of fun and interesting APIs you can try right now: 15 Fun and Interesting APIs to Use for Your Next Coding Project

From jokes and memes to space data and Pokémon info, these APIs are perfect for experimenting and learning by doing.

But only recently, I paused and thought:

“How does localhost actually work? Why does it magically know to point to my computer?”

Turns out, the answer is both simple and cool. Let's explore.

What Is localhost?

At its core, localhost is just a hostname, a label used to refer to a network device.

But unlike google.com or facebook.com, localhost always points to your own computer.

By default, it maps to:

127.0.0.1   // IPv4 loopback address
::1         // IPv6 loopback address

When your browser connects to localhost, it loops back internally to your own system, no router or internet needed.

Where Is This Mapping Stored?

That magic mapping of localhost to 127.0.0.1 happens in a simple text file called the hosts file.

On Windows:

C:\Windows\System32\drivers\etc\hosts

And inside, you’ll usually find:

127.0.0.1   localhost
::1         localhost

These lines tell your system that localhost is just another name for 127.0.0.1.

How Your OS Resolves Hostnames

Whenever you open a URL in your browser, here’s what your OS does:

1. Check the hosts file

2. If not found, ask the DNS server

3. If DNS doesn’t know, show an error

That means your system looks into the hosts file before touching the internet.

So technically, the hosts file is like a mini local DNS. You can override any domain, reroute URLs, and more.

It’s fascinating how something we use every day hides such an elegant little system under the hood.