DEV Community

Cover image for The Language of the Web: HTTP Basics You Actually Need to Know
Zil Norvilis
Zil Norvilis

Posted on • Originally published at norvilis.com

The Language of the Web: HTTP Basics You Actually Need to Know

#webdev #http #beginners #api

HTTP Basics You Must Know As A Web Developer

Very often I see new developers build an entire web application using Rails, React, or Laravel. They know how to write database queries and build components. But the moment they try to connect to a third-party API and get a weird "401 Unauthorized" or "CORS" error, they completely freeze.

The problem is that modern frameworks are almost too good. They hide the raw communication of the internet behind "magic" methods.

Underneath all the Ruby, PHP, and JavaScript, the internet runs on a very simple text-based language called HTTP (Hypertext Transfer Protocol). If you don't understand how HTTP works, debugging web apps is incredibly painful.

Here are the 5 core concepts of HTTP that you absolutely must know to be a confident web developer.

CONCEPT 1: The Request and Response Cycle

HTTP is just a conversation between two computers: the Client (your browser or mobile app) and the Server (your Rails/Node app).

The conversation is strictly turn-based.

  1. The Client asks a question (The Request).
  2. The Server gives an answer (The Response).

The server will never speak to the client unless the client speaks first. (This is why WebSockets were invented later, to allow two-way chatting, but standard HTTP is always a 1-way ask-and-receive).

If you strip away your framework, a raw HTTP Request literally just looks like this simple text:

GET /users HTTP/1.1
Host: api.myapp.com
Accept: application/json
Enter fullscreen mode Exit fullscreen mode

And the Server's Response looks like this:

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

{ "name": "Zil", "role": "admin" }
Enter fullscreen mode Exit fullscreen mode

CONCEPT 2: The Verbs (Methods)

When the Client sends a request, it has to tell the Server what action it wants to perform. We use "Verbs" for this.

If you know database CRUD (Create, Read, Update, Delete), these map perfectly to HTTP verbs.

  • GET (Read): "Give me some data." (e.g., loading a webpage or fetching a user profile). GET requests should never change the database.
  • POST (Create): "Here is some new data, save it." (e.g., submitting a sign-up form).
  • PUT / PATCH (Update): "Here is some updated data, change an existing record." (PATCH is for partial updates, PUT usually replaces the whole record).
  • DELETE (Destroy): "Delete this record."

Rookie Mistake: Never use a GET request to delete a user (like /users/delete/1). If Google's web crawler bots find that link, they will visit it and accidentally delete your users! Always use the correct verb.

CONCEPT 3: Status Codes (The 5 Buckets)

When the Server responds, it gives a 3-digit number called a Status Code. You don't need to memorize all 60 of them. You just need to know the 5 main buckets.

  • 1xx (Informational): "Hang on, I'm thinking." (You rarely see these).
  • 2xx (Success): "Everything went perfectly!"
    • 200 OK: Standard success.
    • 201 Created: Successfully saved a new record.
  • 3xx (Redirection): "The thing you want is over there."
    • 301/302: Redirecting the user to a new URL.
  • 4xx (Client Error): "YOU messed up."
    • 400 Bad Request: You sent missing or invalid data.
    • 401 Unauthorized: You forgot your API key or aren't logged in.
    • 403 Forbidden: You are logged in, but you don't have admin rights to see this.
    • 404 Not Found: You asked for a URL that doesn't exist.
  • 5xx (Server Error): "I (the server) messed up."
    • 500 Internal Server Error: Your backend code crashed. Check your server logs!

CONCEPT 4: Headers (The Hidden Metadata)

Both the Request and the Response have "Headers". Headers are just key-value pairs of hidden information. They are the metadata of the conversation.

As a developer, you will deal with two headers constantly:

1. Content-Type:
This tells the other computer what kind of data is in the body of the message.
If your Rails API sends JSON, but forgets to set Content-Type: application/json, the frontend Javascript might think it's just raw text and crash when trying to parse it.

2. Authorization:
This is how APIs handle security. Instead of sending a username and password every time, you usually pass a token in the headers.

Authorization: Bearer my_secret_api_key_123
Enter fullscreen mode Exit fullscreen mode

CONCEPT 5: Statelessness (The Goldfish Memory)

This is the most important concept to grasp. HTTP is completely stateless.

HTTP has the memory of a goldfish. If you send a request to a server, and then send a second request 1 millisecond later, the server has absolutely no idea that you are the same person. It treats every single request as a brand new stranger.

So, how does a website keep you "logged in"?
Cookies.

When you log in successfully (POST request), the Server's response includes a special header: Set-Cookie: session_id=abc123.
Your browser saves that cookie. On your next request, your browser automatically attaches that cookie in the headers. The server reads the cookie and says, "Ah, I remember this session ID, you are logged in."

Summary

When an API integration breaks, don't just stare at your Ruby or Javascript code. Look at the raw HTTP request in your browser's Network tab.

  1. Did you use the right Verb? (POST instead of GET?)
  2. What was the Status Code? (401 means check your auth token, 500 means check your server logs).
  3. Are your Headers correct? (Is Content-Type set to JSON?)

Once you understand that HTTP is just simple text being passed back and forth, web development becomes a lot less scary and a lot more logical.

Top comments (0)