Toda vez que você digita um endereço no navegador e aperta Enter, uma sequência fascinante de eventos acontece em milissegundos. Entender esse fluxo é a base de tudo no back-end: APIs, autenticação, cache e escalabilidade são apenas variações desse mesmo modelo. Se você domina request e response, domina o resto.
O modelo cliente-servidor
A web funciona com dois papéis: o cliente (seu navegador, um app, um script) faz pedidos, e o servidor responde a eles. O cliente nunca "entra" no servidor — ele apenas envia uma mensagem pedindo algo e espera uma resposta. Essa conversa acontece usando o protocolo HTTP (HyperText Transfer Protocol).
Uma boa analogia é pedir comida num restaurante. Você (cliente) faz um pedido ao garçom (a requisição). A cozinha (servidor) processa. O garçom volta com o prato ou com um "acabou esse ingrediente" (a resposta). Você não entra na cozinha: só envia pedidos e recebe respostas.
O que acontece entre a URL e a página
Ao acessar https://exemplo.com/produtos, vários passos acontecem em ordem:
1. DNS -> "exemplo.com" vira um IP (ex: 93.184.216.34)
2. TCP -> cliente abre uma conexao com o servidor naquele IP
3. TLS -> handshake de criptografia (o "s" do https)
4. HTTP -> cliente envia a requisicao: GET /produtos
5. Server -> processa (consulta banco, monta resposta)
6. HTTP -> servidor devolve a response: 200 OK + HTML/JSON
7. Render -> navegador desenha a paginaO DNS é a "agenda de contatos" da internet: traduz nomes legíveis em endereços IP. O TCP estabelece um canal confiável entre cliente e servidor, e o TLS o criptografa. Só então a requisição HTTP de fato viaja.
Anatomia da requisição
Uma requisição HTTP tem quatro partes. Em entrevista é comum pedir para descrevê-las:
- Método (verbo): o que você quer fazer — GET (ler), POST (criar), PUT/PATCH (atualizar), DELETE (remover).
- Caminho (path): qual recurso —
/produtos,/usuarios/42. - Headers: metadados — tipo de conteúdo, autenticação, idioma.
- Body: os dados enviados (em POST/PUT), geralmente em JSON. GET normalmente não tem body.
POST /produtos HTTP/1.1
Host: exemplo.com
Content-Type: application/json
Authorization: Bearer abc123
{ "nome": "Teclado", "preco": 350 }Anatomia da resposta
A resposta tem três partes: o status code, os headers e o body. O status resume o que aconteceu, agrupado em famílias: 2xx sucesso, 3xx redirecionamento, 4xx erro do cliente, 5xx erro do servidor.
| Status | Significado | Quando aparece |
|---|---|---|
| 200 OK | Sucesso | GET que encontrou o recurso |
| 201 Created | Criado | POST que criou algo |
| 404 Not Found | Não encontrado | Recurso inexistente |
| 500 Server Error | Erro interno | Falha no servidor |
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "nome": "Teclado", "preco": 350 }Por que HTTP é stateless
HTTP é stateless: o servidor não lembra de você entre uma requisição e outra. Cada pedido precisa carregar tudo que o servidor precisa para entendê-lo. É como ligar para uma central de atendimento onde cada ligação cai num atendente diferente que não tem seu histórico — você precisa se identificar toda vez.
Isso parece uma limitação, mas é o que permite escalar: como nenhum servidor guarda "onde você estava", qualquer servidor pode atender qualquer requisição. O estado (quem você é, seu carrinho) é mantido por fora, via cookies, tokens ou banco — assunto de autenticação e autorização.
A web inteira é uma conversa de pedido e resposta sobre um protocolo sem memória. Entender request, response e o porquê do stateless é a fundação de todo o resto do back-end.
Conclusão
Do DNS ao render, cada acesso é uma troca de mensagens entre cliente e servidor sobre HTTP. Saber dissecar uma requisição (método, caminho, headers, body) e uma resposta (status, headers, body), e entender por que HTTP é stateless, é o conhecimento que sustenta APIs REST, sessões e escalabilidade. Domine esse fluxo e você terá o mapa de tudo que vem depois.
Every time you type an address in the browser and hit Enter, a fascinating sequence of events happens in milliseconds. Understanding this flow is the foundation of everything in the back-end: APIs, authentication, caching and scalability are all just variations of this same model. If you master request and response, you master the rest.
The client-server model
The web works with two roles: the client (your browser, an app, a script) makes requests, and the server responds to them. The client never "gets inside" the server — it just sends a message asking for something and waits for a response. This conversation happens using the HTTP protocol (HyperText Transfer Protocol).
A good analogy is ordering food at a restaurant. You (the client) place an order with the waiter (the request). The kitchen (the server) processes it. The waiter comes back with the dish or with a "we're out of that ingredient" (the response). You don't walk into the kitchen: you just send orders and receive responses.
What happens between the URL and the page
When you visit https://example.com/products, several steps happen in order:
1. DNS -> "example.com" becomes an IP (e.g. 93.184.216.34)
2. TCP -> client opens a connection to the server at that IP
3. TLS -> encryption handshake (the "s" in https)
4. HTTP -> client sends the request: GET /products
5. Server -> processes it (queries the database, builds the response)
6. HTTP -> server returns the response: 200 OK + HTML/JSON
7. Render -> browser draws the pageDNS is the internet's "contact book": it translates readable names into IP addresses. TCP establishes a reliable channel between client and server, and TLS encrypts it. Only then does the HTTP request actually travel.
Anatomy of a request
An HTTP request has four parts. In interviews you're often asked to describe them:
- Method (verb): what you want to do — GET (read), POST (create), PUT/PATCH (update), DELETE (remove).
- Path: which resource —
/products,/users/42. - Headers: metadata — content type, authentication, language.
- Body: the data sent (in POST/PUT), usually as JSON. GET normally has no body.
POST /products HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer abc123
{ "name": "Keyboard", "price": 350 }Anatomy of a response
The response has three parts: the status code, the headers and the body. The status sums up what happened, grouped into families: 2xx success, 3xx redirection, 4xx client error, 5xx server error.
| Status | Meaning | When it shows up |
|---|---|---|
| 200 OK | Success | GET that found the resource |
| 201 Created | Created | POST that created something |
| 404 Not Found | Not found | Nonexistent resource |
| 500 Server Error | Internal error | Server failure |
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Keyboard", "price": 350 }Why HTTP is stateless
HTTP is stateless: the server doesn't remember you between one request and the next. Each request has to carry everything the server needs to understand it. It's like calling a support center where every call lands on a different agent who has no record of your history — you have to identify yourself every time.
This looks like a limitation, but it's what makes scaling possible: since no server keeps track of "where you were", any server can handle any request. State (who you are, your cart) is kept elsewhere, through cookies, tokens or a database — the subject of authentication and authorization.
The whole web is a request-and-response conversation over a protocol with no memory. Understanding request, response and why stateless matters is the foundation of everything else in the back-end.
Conclusion
From DNS to render, every visit is an exchange of messages between client and server over HTTP. Knowing how to dissect a request (method, path, headers, body) and a response (status, headers, body), and understanding why HTTP is stateless, is the knowledge that underpins REST APIs, sessions and scalability. Master this flow and you'll have the map for everything that comes after.