What is a Server, and Why Would You Talk to It?

Every time you open a website, your browser is having a conversation with a computer somewhere in the world. That computer is called a server.

When you visit google.com:

1. Your browser sends a message: "Hey Google, give me your homepage"
2. Google's server responds: "Here it is"
3. Your browser displays the page

This conversation happens using HTTP — a language that browsers and servers both understand.

But here's the thing: browsers aren't the only way to talk to servers. Sometimes you need to talk to a server directly, without a browser getting in the way.

That's where cURL comes in.

What is cURL?

cURL (pronounced "curl") stands for "Client URL." It's a command-line tool that lets you send requests to servers and see their responses — just like a browser does, but from your terminal.

Think of it this way:

• A browser is like making a phone call with a fancy smartphone app that shows caller ID, adds filters, and displays everything nicely
• cURL is like making a phone call with a basic landline — raw and direct

Both make the call. But cURL shows you exactly what's happening, with nothing hidden.

Why Do Programmers Need cURL?

Browsers are great for browsing. But programmers need more control.

Testing APIs — Before writing code to call an API, you can manually test if it works and what it returns.

Debugging — See exactly what a server sends back, including headers, status codes, and error messages.

Automation — Scripts can use cURL to fetch data, send notifications, or interact with services without human interaction.

No browser needed — Servers don't have browsers installed. When you're working on a remote server, cURL is often the only option.

If you're building backend systems, you'll use cURL almost daily

Where cURL Fits in Development

Browsers are for users. cURL is for developers testing and debugging. Code is for production. They all talk to the same server — just in different contexts.

Making Your First Request

Let's start simple. Open your terminal and type:

curl https://example.com

Press Enter. You'll see something like this:

    Example Domain
...




    
Example Domain
    
This domain is for use in illustrative examples...

That's it. You just fetched a webpage using cURL.

What happened:

1. cURL sent a request to example.com
2. The server responded with HTML
3. cURL printed that HTML to your terminal

A browser would render this HTML as a pretty page. cURL just shows you the raw response.

Understanding Request and Response

Every HTTP conversation has two parts.

The Request (What You Send)

When you run curl https://example.com, cURL sends something like:

GET / HTTP/1.1
Host: example.com

This says: "I want to GET the main page (/) from example.com."

The Response (What You Receive)

The server sends back:

HTTP/1.1 200 OK
Content-Type: text/html


...

This includes:

• Status code — 200 OK means success
• Headers — metadata about the response (like content type)
• Body — the actual content (HTML, JSON, whatever)

  

• 
  

• To see the full response including headers, use the -i flag:

• curl -i https://example.com
  
  

• Now you'll see both the headers and the body

  ---

• Two Types of Requests: GET and POST

• For now, you only need to know two request types.

• GET — Asking for Data

• GET requests fetch information. When you visit a webpage or search for something, that's a GET request.

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

• This says: "Give me the list of users."

• GET is the default. If you don't specify a method, cURL uses GET.

• POST — Sending Data

• POST requests send information to the server. When you submit a form, create an account, or upload something, that's a POST request.

• curl -X POST https://api.example.com/users \
    -H "Content-Type: application/json" \
    -d '{"name": "Alice", "email": "[email protected]"}'
  
  

• Let's break this down:

• • -X POST — Use the POST method instead of GET

• • -H "Content-Type: application/json" — Tell the server we're sending JSON data

• • -d '{"name": "Alice"...}' — The actual data we're sending

• This says: "Create a new user with this information."

  ---

• 
  

• Using cURL to Talk to APIs

• APIs (Application Programming Interfaces) are how programs talk to each other. Most modern APIs use JSON — a simple data format that looks like this:

• {
    "name": "Alice",
    "email": "[email protected]"
  }
  
  

• Fetching data from a public API:

• curl https://jsonplaceholder.typicode.com/posts/1
  
  

• Response:

• {
    "userId": 1,
    "id": 1,
    "title": "sunt aut facere repellat provident",
    "body": "quia et suscipit..."
  }
  
  

• This is real data from a real API. No browser, no code — just cURL.

• Sending data to an API:

• curl -X POST https://jsonplaceholder.typicode.com/posts \
    -H "Content-Type: application/json" \
    -d '{"title": "My Post", "body": "Hello world", "userId": 1}'
  
  

• Response:

• {
    "title": "My Post",
    "body": "Hello world",
    "userId": 1,
    "id": 101
  }
  
  

• The server created a new post and returned it with an ID. This is the pattern for most API interactions: send a request, receive a response

  ---

• Common Mistakes Beginners Make

• Forgetting the Protocol

• # Wrong
  curl example.com
  
  # Right
  curl https://example.com
  
  

• Always include http:// or https://. Without it, cURL might not know what protocol to use.

• Missing Content-Type for POST Requests

• # Wrong — server doesn't know what format you're sending
  curl -X POST https://api.example.com/users \
    -d '{"name": "Alice"}'
  
  # Right — tell the server it's JSON
  curl -X POST https://api.example.com/users \
    -H "Content-Type: application/json" \
    -d '{"name": "Alice"}'
  
  

• When sending JSON, always include -H "Content-Type: application/json".

• Not Checking the Status Code

• A response doesn't mean success. Use -i to see the status code:

• curl -i https://api.example.com/users
  
  

• Common status codes:

• • 200 — Success

• • 201 — Created (for POST requests that create something)

• • 400 — Bad request (you sent something wrong)

• • 401 — Unauthorized (you need to log in or provide an API key)

• • 404 — Not found

• • 500 — Server error (something broke on their end)

• Quote Problems with JSON

• On most systems, JSON data needs single quotes outside and double quotes inside:

• # Correct on Linux/Mac
  -d '{"name": "Alice"}'
  
  # Often problematic
  -d "{"name": "Alice"}"
  
  

• On Windows Command Prompt, quote handling is different. You may need to escape the inner quotes or use a different approach.

• Trying to Do Too Much at Once

• Start simple. Fetch a webpage. Then add headers. Then try POST. Don't jump straight to complex multi-header authenticated requests.

  ---

• 
  

• Useful Flags to Know

• -i — Include response headers in the output.

• curl -i https://example.com
  
  

• -X — Specify the HTTP method (GET, POST, PUT, DELETE).

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

• -H — Add a header to the request.

• curl -H "Authorization: Bearer token123" https://api.example.com/me
  
  

• -d — Send data in the request body.

• curl -d '{"name": "Alice"}' https://api.example.com/users
  
  

• -o — Save the response to a file.

• curl -o page.html https://example.com
  
  

• -v — Verbose mode. Shows everything — the full request sent and the full response received. Great for debugging.

• curl -v https://example.com
  
    
  
  
  
  

• A Typical Workflow

• Before writing code to call an API, test it with cURL first:

• Read the API documentation

• Try a simple GET request to see what data looks like

• Try POST requests to create or update data

• Note the headers you need (authentication, content type)

• Once it works in cURL, translate it to your programming language

• This workflow saves time. You'll discover problems with the API (or your understanding of it) before writing any code
  
    
  
  

• Wrapping Up
  

• cURL is a conversation tool. It lets you talk to servers, see exactly what they respond with, and test APIs without writing any code.
  

• Start simple: fetch a few webpages with curl https://.... Look at the responses. Add -i to see headers. Try a public API. Experiment with POST requests.
  

• Once you're comfortable, cURL becomes indispensable. Every backend developer uses it daily — for testing, debugging, and exploring how things work under the hood.
  

• .

• .

• .

.