Skip to main content

Command Palette

Search for a command to run...

Getting Started with cURL

Talking to Servers Without a Browser

Updated
4 min read
Getting Started with cURL

Introduction
Welcome to the final part of our "From Wire to Web" series!

  • Part 1: We learned how data travels from the ocean to your router.

  • Part 2 & 3: We learned how dig finds the IP address of the server.

Now, we are standing at the door of the server. We have the address. But how do we talk to it? Most of us use a Browser (Chrome/Brave). But as developers, sometimes we don't need the buttons and images. Sometimes, we just want to send a raw message to the server. That is where cURL comes in.

What is cURL? cURL (Client URL) is a command-line tool that lets you transfer data to or from a server.

  • The Browser: It’s like a restaurant with a waiter, a menu with pictures, and nice music. You point at a picture to order.

  • cURL: It’s like a walkie-talkie connected directly to the kitchen. You press a button and say, "Give me a burger." No waiter, no pictures, just raw communication.

Why do programmers need it?

  1. Debugging: If your API isn't working, the browser might hide the real error message behind a "404 Page." cURL shows you the exact raw response.

  2. Automation: You can't write a script to "click a button" in Chrome easily. But you can write a script to run a cURL command 1,000 times in a second.

  3. No UI Needed: When you are working on a remote server (backend), there is no screen. cURL is your only way to talk to the internet.

Making Your First Request Let’s try the simplest command. We will fetch the Google homepage. Open your terminal and type:

curl google.com

What happened? You probably saw a huge mess of code on your screen. That is HTML. When you visit google.com in Chrome, the browser takes this code and paints it into a nice search bar. cURL doesn't paint. It just dumps the raw data. (Proof that the browser is just a fancy cURL wrapper!)

Understanding the Conversation (Request & Response) Computers are polite. They follow a conversation structure:

  1. Request (You): "Hey, give me this page."

  2. Response (Server): "Okay, here is the data."

To see this "Handshake," use the -v (verbose) flag.

curl -v google.com

Look at the output. Lines starting with > are your Request. Lines starting with < are the Server's Response. You will see something like HTTP/1.1 200 OK.

  • 200: This is the Status Code. It means "Success!"

  • 301: "Moved Permanently" (Go look somewhere else).

  • 404: "Not Found" (I don't have that).

  • 500: "Server Error" (I crashed).

Talking to APIs (GET vs POST) cURL is mostly used to talk to APIs (Application Programming Interfaces). There are two main ways to talk:

1. GET (Asking for data) This is the default. You are just retrieving information.

curl https://jsonplaceholder.typicode.com/posts/1
  • You get a nice JSON response (data), not HTML.

2. POST (Sending data) This is when you want to create something, like posting a Tweet or submitting a form. You need to send data to the server.

curl -X POST https://jsonplaceholder.typicode.com/posts \
     -d "title=My First Post&body=Hello World"
  • -X POST: Tells cURL "I am sending data, not just asking."

  • -d: Stands for "Data". This is the message you are sending.

Common Mistakes Beginners Make

  1. Forgetting https://: If you just type curl google.com, some servers might ignore you. Always use the full URL.

  2. Not using Quotes: When sending data (-d), always use quotes "like this". If you don't, the terminal gets confused by spaces.

  3. Fear of the Terminal: The output looks scary (lots of text). Don't panic. Scroll up and look for the specific HTTP code (200, 404, etc).

Conclusion Congratulations! You have completed the "From Wire to Web" journey.

  1. We traced the Undersea Cables.

  2. We looked up the DNS Records.

  3. We used dig to find the IP.

  4. And now, we used curl to talk to the server.

You now understand the "Invisible Internet" better than 90% of people. Go build something awesome!
In the next series, we are opening the Browser's Black Box. We will look at how the Rendering Engine( stop saying display, rendering is for devs ) paints pixels on your screen.

From Wire to Web

Part 1 of 6

Grab a chai ☕. We trace a data packet from the ocean floor to your screen. Master the "invisible" stack: Modems, Routers, DNS, and cURL. Networking explained for humans, not robots.

Up next

TCP Internals; Handshake, Delivery, and Goodbye

TCP is the "Safe Mode", But how does it actually guarantee safety?

More from this blog

T

The Engineering Log

18 posts

Documenting the journey from bits to architecture. A technical archive exploring internals, engineering, infrastructure, and the systems that power modern software. Written by Mayur Badgujar.