HTTP

Every web interaction is one simple thing. A question and an answer.

Just a question and an answer

HTTP stands for HyperText Transfer Protocol. The name sounds complicated. The idea is simple. The client asks. The server answers.

That is it. Every page load, every API call, every form you submit on a website is one of these little exchanges.

The client says, "I want this page. Here is a bit of info about me." The server replies, "Here is what you asked for." Or sometimes, "I cannot give that to you because of this reason."

Everything else in HTTP is just a way to be more specific about what was asked and what was returned. The methods, the status codes, the headers. We will look at each one next.

Methods. What do you want to do?

Every request includes a method. The method is a verb. It tells the server what kind of action you want.

GET means "give me this thing." Loading a page, reading a tweet, fetching an image. A GET should not change anything on the server.

POST means "I am sending you something new." Filling out a form, posting a comment, creating a new account.

PUT means "replace what is there with this." Updating a user profile from scratch.

PATCH means "change just this one part." Updating a single field.

DELETE means "remove this thing."

These are conventions, not hard rules. A server could technically do anything for any method. But well-built APIs stick to these meanings so other developers can guess what they do.

Status codes. What did the server say?

Every response from the server comes with a three-digit number called a status code. The first digit tells you the broad category.

2xx codes mean success. The most common is 200 OK. Then 201 Created when something new was made, and 204 No Content when something worked but there is nothing to send back.

3xx codes mean redirect. Like 301 Moved Permanently when the page lives somewhere else now.

4xx codes mean you (the client) did something wrong. 400 Bad Request if you sent something the server cannot read. 401 Unauthorized if you need to log in. 403 Forbidden if you are logged in but not allowed. 404 Not Found when the thing does not exist. 429 Too Many Requests when you are sending too fast.

5xx codes mean the server messed up. 500 Internal Server Error if the server crashed. 503 Service Unavailable if it is down for maintenance.

You will see 200, 404, and 500 the most. Memorize those three and you understand most of the web.

Headers. Extra info on the side

Both requests and responses carry headers. Headers are little notes about the message. They are not the actual content. They describe it.

Request headers tell the server about you. User-Agent says which browser you are using. Cookie carries your session ID so the server knows it is still you. Authorization can carry an API key or token.

Response headers tell you about what is coming back. Content-Type says whether the response is HTML, JSON, an image, or something else. Cache-Control tells your browser whether it can save the response and reuse it next time.

A lot of important stuff in the web runs on headers. Logging in, caching, security, language preferences. All of it.

HTTP forgets you after every request

Here is something important. HTTP itself has no memory. The server treats each request as totally independent. By default, it does not know if two requests came from the same person.

So how does logging in work? Cookies and tokens. When you log in, the server hands your browser a small token. Your browser includes that token on every future request. The server reads it and says, "I remember this person. It is user number 42."

You might think it is a problem that HTTP is forgetful. But it is actually a useful feature. Because the server does not have to remember anything about you between requests, you can run many copies of the server behind a load balancer. Any one of them can handle any request because each request brings its own context. We will see how this works in the next few lessons.

Now build it yourself →