HTTP Methods & Status Codes

Every time you use an app, your phone is sending little messages to a server and getting answers back. Like, you open Instagram and it asks the server “give me my feed”. You like a photo and it tells the server “save this like”. So here’s the thing you should be wondering:

• How does the app say what it wants to do, not just what data it wants?
• And how does the server tell you “all good” or “that didn’t work”?

That’s the job of HTTP methods and status codes. Methods say what you want to do. Status codes say how it went. Let’s break both down, because you’ll see them every single day as a developer.

🎯 What is an HTTP Request

Before methods and codes, let’s quickly see the shape of a request. When your app talks to a server, it sends an HTTP request, and that request has a few clear parts.

• A method, like GET or POST. This says what action you want.
• A URL, like /users/42. This says which thing you’re acting on.
• Headers, which are little extra notes, like who you are or what format you want back.
• A body (sometimes), which is the actual data you’re sending, like a new comment.

The server reads all that, does the work, and sends back an HTTP response, which carries a status code and usually some data. So request goes out, response comes back. Simple loop.

🔧 HTTP Methods

A method is the verb of your request. It tells the server what kind of action you want to take on the thing at that URL. Here are the common ones, one line each:

• GET means “give me this thing.” Reading only, it doesn’t change anything. Like loading a profile page.
• POST means “create a new thing.” Like posting a new comment or signing up a new user.
• PUT means “replace this whole thing with what I’m sending.” Like updating a full profile.
• PATCH means “change just this one part.” Like updating only your phone number.
• DELETE means “remove this thing.” Like deleting a photo.

Here’s a quick way to remember it: GET reads, POST creates, PUT and PATCH update, DELETE removes.

There’s one important idea about GET. A GET should never change data on the server. It only reads. This matters because browsers and caches assume GET is safe to repeat. So if you make a GET that secretly deletes something, you’re asking for trouble.

📦 What a Request Looks Like

Let me show you a real request so the parts feel concrete. Here’s what your app sends when it creates a new comment.

POST /posts/42/comments HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "text": "Great photo!"
}

Let’s read it line by line.

• POST /posts/42/comments is the method and the URL. You want to create a comment on post 42.
• Host and Content-Type are headers. They say which server, and that the body is JSON.
• The part in curly braces is the body, the actual data you’re sending.

The server takes this, saves the comment, and replies with a status code. Which brings us to the next part.

🚦 HTTP Status Codes

A status code is a three-digit number the server sends back to say how the request went. You don’t have to memorize all of them. Just learn the groups, because the first digit tells you the category.

That 4xx vs 5xx split is the one to really get. 4xx is your fault (the client sent a bad request). 5xx is the server’s fault (it broke while handling a fine request).

🔢 The Codes You’ll See Most

Within those groups, a handful show up again and again. Learn these and you’ll recognize almost everything in daily work:

• 200 OK means it worked. The most common success code.
• 201 Created means a POST worked and made a new thing.
• 301 / 302 mean the page moved to a new URL, so go there instead.
• 400 Bad Request means the request was malformed, like a missing field.
• 401 Unauthorized means you’re not logged in or your token is bad.
• 403 Forbidden means you’re logged in, but you’re not allowed to do this.
• 404 Not Found means the thing you asked for doesn’t exist.
• 500 Internal Server Error means the server crashed while handling your request.
• 503 Service Unavailable means the server is up but too busy or down for maintenance.

🏗️ Putting It Together

So a full round trip uses both ideas at once: a method going out, a status code coming back. Here’s the flow for liking a photo.

Reading that:

• The app sends a POST to create a like, and the server replies 201 Created.
• Then the app sends a GET to read the photo again, and the server replies 200 OK with the data.

Method says what you want, status code says how it went. That pairing is the heartbeat of almost every app you’ll build.

⚠️ Common Mistakes and Misconceptions

A few wrong ideas show up early. Let’s clear them:

• “Use POST for everything.” Tempting, but wrong. Using the right method (GET to read, DELETE to remove) makes your API predictable and lets caches and tools work properly.
• “Any error should be 500.” No. If the client sent a bad request, that’s a 4xx. Save 5xx for when your server actually breaks. Mixing these up makes bugs very hard to track.
• “200 means everything is fine.” Not always. Some servers return 200 with an error message hidden in the body. That’s poor design. The status code should tell the truth on its own.

🧩 What You’ve Learned

Nice work. Here’s the recap:

• ✅ An HTTP request has a method, a URL, headers, and sometimes a body. The response carries a status code and data.
• ✅ Methods are verbs: GET reads, POST creates, PUT and PATCH update, DELETE removes.
• ✅ GET must never change data, because it’s assumed safe to repeat.
• ✅ Status codes come in groups: 2xx success, 3xx redirect, 4xx client error, 5xx server error.
• ✅ The codes you’ll see most are 200, 201, 301/302, 400, 401, 403, 404, 500, and 503.

🚀 What’s Next?

You now know how apps say what they want and how servers reply. Let’s keep building on the request journey.

• HTTP vs HTTPS shows how that request is kept safe and private.
• REST APIs Explained shows how these methods come together into a clean, predictable API.

Get these down and the way apps talk to servers will start to feel obvious.