Skip to main content
Hashnodecurlexplained29

Command Palette

Search for a command to run...

CURL Explained Simply

Published
•7 min read•View as Markdown
B
Baibhav Tibrewal

Before cURL: what is a server?

Before we talk about cURL, we need one simple idea.

A server is just a computer on the internet that:

  • Waits for requests

  • Does some work

  • Sends back a response

When you open a website, your browser sends a request to a server.
The server replies with data.

This request–response conversation is the foundation of the web.

Why we need a way to talk to servers

Most of the time, browsers talk to servers for us.

But developers often need to:

  • Test APIs

  • Debug backend issues

  • Call servers without a UI

  • Automate requests

For this, we need a direct way to talk to servers.

That is where cURL comes in.

What is cURL (in very simple terms)

cURL is a tool that lets you send requests to a server from the terminal.

That’s it.

Think of cURL as:

  • A browser without buttons

  • A message sender for servers

  • A way to speak HTTP by hand

Instead of clicking links, you type commands.

Why programmers need cURL

cURL is useful because it:

  • Works everywhere (Linux, macOS, Windows)

  • Does not depend on UI

  • Shows raw request and response

  • Is fast and scriptable

Backend developers, DevOps engineers, and testers all rely on it.

If you work with APIs, cURL becomes unavoidable.

Making your first request using cURL

Let’s start with the simplest possible command.

curl https://example.com

What this does

  • Sends a GET request to the server

  • Asks for the resource at /

  • Prints the response in your terminal

You just fetched a webpage without a browser.

What just happened (request and response)

Every cURL command follows the same flow:

  1. You send a request

  2. The server processes it

  3. The server sends a response

Request contains:

  • Method (GET, POST)

  • URL

  • Optional data

Response contains:

  • Status code (200, 404, 500)

  • Headers (metadata)

  • Body (actual data)

cURL shows you the raw result.

Understanding HTTP status codes (briefly)

You don’t need to memorize them.
Just understand the idea:

  • 200 → Success

  • 400 → You sent something wrong

  • 500 → Server failed

Status codes tell you how the server felt about your request.

GET vs POST (only what you need)

GET

  • Used to fetch data

  • No side effects

Example:

curl https://api.example.com/users

POST

  • Used to send data

  • Often creates or updates something

Example:

curl -X POST https://api.example.com/users

That’s enough for now.

Using cURL to talk to APIs

APIs are just servers expecting structured requests.

Example API call:

curl https://api.github.com

Instead of HTML, you’ll receive JSON.

This is how backend systems talk to each other.

Seeing headers vs seeing data

By default, cURL shows only the response body.

Conceptually:

  • Headers = envelope

  • Body = letter inside

As a beginner, focus on the body first.
Headers become important later.

Common mistakes beginners make with cURL

1. Expecting a browser-like output

cURL shows raw data, not styled pages.
That’s normal.

2. Forgetting the protocol

example.com ❌
https://example.com ✅

3. Mixing GET and POST mentally

GET reads.
POST sends.

4. Copy-pasting complex commands too early

Too many flags hide the basics.
Learn the flow first.

Browser request vs cURL request (conceptual)

  • Browser adds cookies, headers, JS

  • cURL sends exactly what you tell it

That’s why cURL is great for debugging.

Same server.
Different tools.

Where cURL fits in backend development

cURL is often used to:

  • Test APIs during development

  • Reproduce production bugs

  • Verify deployments

  • Learn how systems talk

Many tools (Postman, Swagger) are built on the same ideas.
cURL is the foundation.

Mental model to remember

Think of cURL as:

A walkie-talkie between you and a server.

You speak clearly.
The server replies honestly.

Going deeper: what really happens when you run a cURL command

Let’s slow things down and look at what actually happens internally when you type a cURL command.

curl https://api.example.com/users

This single line triggers a full client–server interaction.

Step 1: URL parsing

cURL first breaks the URL into parts:

  • Protocol → https

  • Host → api.example.com

  • Path → /users

  • Port → 443 (default for HTTPS)

If DNS is involved, cURL now resolves the domain name to an IP address.

At this point:

  • DNS lookup happens (A / AAAA record)

  • An IP address is selected

Step 2: TCP connection

Once the IP address is known, cURL establishes a TCP connection.

Think of TCP as:

“Let’s open a reliable communication pipe.”

This involves:

  • SYN

  • SYN-ACK

  • ACK

You don’t see this, but it always happens.

Step 3: TLS handshake (for HTTPS)

If the URL uses HTTPS, another step happens:

  • SSL/TLS handshake

  • Server certificate verification

  • Encryption keys agreed

Only after this does HTTP start.

This is why HTTPS feels slower the first time.

Step 4: HTTP request is sent

Now cURL sends the HTTP request.

A simplified GET request looks like:

GET /users HTTP/1.1
Host: api.example.com
User-Agent: curl/8.x
Accept: */*

This is the actual message the server receives.

Step 5: Server processes the request

On the server side:

  • Request hits a web server (Nginx / Apache)

  • Routed to application code

  • Database or logic is executed

  • Response is prepared

This is where backend bugs live

Step 6: HTTP response is returned

The server replies with something like:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 128

[{"id":1,"name":"Alice"}]

This response has three layers:

  1. Status line

  2. Headers

  3. Body

Deep dive: understanding the response clearly

Status line

Tells you:

  • Did it work?

  • Who is at fault if it didn’t?

Examples:

  • 200 OK → Success

  • 401 Unauthorized → Auth missing

  • 404 Not Found → Wrong URL

  • 500 Internal Server Error → Server bug

Headers (metadata)

Headers describe the response:

  • Content type

  • Encoding

  • Caching rules

  • Security info

Example:

Content-Type: application/json

This tells the client how to interpret the body.

Body (actual data)

This is what you usually care about:

  • HTML

  • JSON

  • XML

  • Plain text

APIs mostly return JSON.

GET vs POST (deeper intuition)

GET

  • Read-only

  • Idempotent (safe to repeat)

  • Parameters usually in URL

curl "https://api.example.com/users?id=1"

POST

  • Sends data

  • Changes server state

  • Data goes in the request body

curl -X POST https://api.example.com/users \
     -d '{"name":"Bob"}'

Think:

  • GET = asking a question

  • POST = submitting a form

cURL and APIs (real-world usage)

Most APIs expect:

  • Method (GET / POST)

  • Headers (Content-Type, Authorization)

  • Body (JSON)

cURL lets you control all three explicitly.

This is why backend developers love it.

Seeing what cURL is really sending

A powerful learning trick:

curl -v https://example.com

This shows:

  • DNS resolution

  • TCP connection

  • TLS handshake

  • Request headers

  • Response headers

This single flag reveals everything.

Why beginners struggle with cURL

The problem is not cURL.

The problem is that cURL exposes raw networking reality.

Browsers hide:

  • DNS

  • TLS

  • Headers

  • Redirects

cURL shows all of it.

Once you accept this, cURL becomes your best teacher.

Where cURL fits in system design

cURL helps you understand:

  • Client–server boundaries

  • API contracts

  • Network failures

  • Timeouts and retries

Every microservice call behaves like a cURL request.

Final mental model

Think of cURL as:

A microscope for HTTP communication.

It doesn’t beautify.
It reveals truth.

Final takeaway

  • cURL is simple on the surface

  • Deep underneath, it touches DNS, TCP, TLS, and HTTP

  • Learning cURL means learning how the web really works

#curl#curl-command#curl-for-beginner

Comments

Join the discussion

No comments yet. Be the first to comment.