Como a Web Funciona: navegador, servidor, backend, banco de dados, HTTP e JSON

Introdução

Todo site parece simples para quem está usando.

Você digita um endereço no navegador, aperta Enter e a página aparece. Quando clica em um botão, alguma coisa acontece. Quando faz login, o sistema confirma seus dados. Quando compra um produto, o pedido é registrado. Quando abre uma rede social, novas publicações aparecem na tela.

Mas por trás dessa aparente simplicidade existe um caminho inteiro acontecendo em poucos segundos.

O navegador conversa com a internet. A internet encontra o servidor. O servidor executa uma aplicação. A aplicação pode consultar um banco de dados. O banco devolve informações. O backend prepara uma resposta. O frontend exibe o resultado na tela.

Esse fluxo é a base de praticamente qualquer sistema web moderno.

Não importa se a aplicação foi criada com Java, PHP, Python, JavaScript, Node.js, C#, Ruby, Go, Laravel, Spring Boot, Django, Express, Rails ou qualquer outra tecnologia. Por trás de todas elas existe a mesma ideia principal: uma comunicação entre cliente, servidor e dados.

Nesta lição, você vai entender como a web funciona de verdade. Não vamos focar em uma linguagem específica. A ideia é compreender o caminho completo que uma aplicação percorre até aparecer na tela do usuário.

Esse conhecimento é essencial para qualquer pessoa que deseja se tornar desenvolvedor fullstack, backend, frontend, DevOps ou arquiteto de software.

Objetivo da lição

O objetivo desta aula é entender o fluxo básico de uma aplicação web:

Usuário
↓
Navegador
↓
DNS
↓
Internet
↓
Servidor
↓
Backend
↓
Banco de dados
↓
Resposta
↓
Navegador
↓
Tela do usuário

Quando você entende esse caminho, deixa de enxergar programação como apenas “escrever código” e começa a enxergar sistemas como um conjunto de partes que trabalham juntas.

Essa visão é o que diferencia alguém que apenas copia comandos de alguém que realmente entende como uma aplicação funciona.

1. O que acontece quando você acessa um site?

Imagine que você digita este endereço no navegador:

https://meusite.com/produtos

Para o usuário, parece que o navegador simplesmente abre uma página. Porém, internamente, várias etapas acontecem.

A primeira coisa que o navegador precisa descobrir é onde esse site está hospedado. Para isso, ele usa o DNS.

DNS significa Domain Name System, ou Sistema de Nomes de Domínio.

Em vez de você decorar um endereço numérico, como um IP, você usa um nome mais fácil de lembrar, como:

meusite.com
cursojavanow.com.br
google.com
github.com

O DNS funciona como uma espécie de lista de endereços da internet. Ele ajuda a transformar um nome de domínio em um endereço que os computadores conseguem localizar.

De forma simplificada, o fluxo começa assim:

meusite.com
↓
consulta DNS
↓
IP do servidor
↓
conexão com o servidor

Depois que o navegador descobre para onde deve ir, ele envia uma requisição para o servidor.

Essa requisição normalmente usa o protocolo HTTP ou HTTPS.

2. O que é HTTP?

HTTP significa Hypertext Transfer Protocol.

De forma simples, HTTP é o protocolo usado para a comunicação entre cliente e servidor na web.

O cliente geralmente é o navegador, como Chrome, Firefox, Edge ou Safari. O servidor é a máquina onde a aplicação está hospedada.

Quando você acessa uma página, o navegador faz uma requisição HTTP. O servidor recebe essa requisição e devolve uma resposta HTTP.

A conversa básica é esta:

Navegador:
"Servidor, quero acessar /produtos."

Servidor:
"Ok, aqui está a resposta."

Essa resposta pode ser uma página HTML, um arquivo CSS, um JavaScript, uma imagem, um JSON, um PDF ou qualquer outro recurso disponível na web.

3. HTTP e HTTPS são a mesma coisa?

HTTP e HTTPS são parecidos, mas não são exatamente a mesma coisa.

O HTTP é o protocolo de comunicação.

O HTTPS é a versão segura dessa comunicação. Ele usa criptografia para proteger os dados enviados entre o navegador e o servidor.

Na prática, quando você acessa:

http://meusite.com

a comunicação não está protegida da mesma forma.

Quando acessa:

https://meusite.com

a comunicação passa por uma camada de segurança.

Por isso, sites modernos devem usar HTTPS, principalmente quando lidam com login, senha, pagamentos, formulários, dados pessoais ou qualquer informação sensível.

Para o usuário comum, o HTTPS costuma aparecer como um cadeado no navegador.

Para o desenvolvedor, ele é uma parte importante da segurança da aplicação.

4. O que é uma requisição HTTP?

Uma requisição HTTP é o pedido que o cliente envia para o servidor.

Quando o navegador acessa uma página, ele envia algo parecido com isto:

GET /produtos HTTP/1.1
Host: meusite.com
Accept: text/html

Essa requisição diz:

Método: GET
Caminho: /produtos
Protocolo: HTTP/1.1
Servidor desejado: meusite.com
Tipo de resposta esperada: HTML

Em uma aplicação real, a requisição pode carregar mais informações, como:

Cookies
Token de autenticação
Idioma do navegador
Tipo de conteúdo aceito
Dados de formulário
Parâmetros de busca
Cabeçalhos de segurança

Ou seja, a requisição não é apenas “abrir uma página”. Ela é uma mensagem estruturada enviada do cliente para o servidor.

5. O que é uma resposta HTTP?

Depois que o servidor recebe a requisição, ele processa o pedido e devolve uma resposta.

Uma resposta HTTP pode ser parecida com isto:

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

{
  "id": 10,
  "nome": "Curso Java Now"
}

Essa resposta tem três partes importantes:

Status da resposta
Cabeçalhos
Corpo da resposta

O status indica se deu certo ou se houve algum problema.

Os cabeçalhos trazem informações adicionais, como tipo de conteúdo, cache, cookies e segurança.

O corpo é o conteúdo principal da resposta. Pode ser HTML, JSON, texto, imagem ou outro formato.

6. O que são status codes?

Status codes são códigos que indicam o resultado de uma requisição HTTP.

Eles ajudam o navegador, o frontend, o backend e o desenvolvedor a entenderem o que aconteceu.

Veja alguns exemplos comuns:

Esses códigos aparecem o tempo todo em aplicações reais.

Quando uma página não existe, normalmente aparece um erro 404.

Quando um usuário tenta acessar uma área protegida sem estar logado, pode aparecer um erro 401.

Quando o usuário está logado, mas não tem permissão para acessar determinada área, pode aparecer 403.

Quando a aplicação quebra no servidor, pode aparecer 500.

Entender status codes ajuda muito na hora de debugar problemas.

7. O que são métodos HTTP?

Os métodos HTTP indicam a intenção da requisição.

Os mais usados em APIs e aplicações web são:

GET
POST
PUT
PATCH
DELETE

Cada um tem um papel.

GET

O método GET é usado para buscar informações.

Exemplo:

GET /produtos

Significa:

Servidor, me entregue a lista de produtos.

Outro exemplo:

GET /produtos/10

Significa:

Servidor, me entregue os dados do produto 10.

O GET não deve ser usado para criar, alterar ou remover dados. Ele deve ser usado para consulta.

POST

O método POST é usado para criar algo novo ou enviar dados para processamento.

Exemplo:

POST /produtos

Significa:

Servidor, cadastre este novo produto.

O corpo da requisição poderia ser:

{
  "nome": "Notebook",
  "preco": 3500.00
}

O backend recebe esses dados, valida as informações e pode gravar o novo produto no banco de dados.

PUT

O método PUT é usado para substituir ou atualizar um recurso inteiro.

Exemplo:

PUT /produtos/10

Significa:

Servidor, atualize completamente o produto de código 10.

O corpo da requisição poderia ser:

{
  "nome": "Notebook Gamer",
  "preco": 5200.00,
  "estoque": 8
}

A ideia do PUT é enviar a nova representação completa do recurso.

PATCH

O método PATCH é usado para alterar apenas parte de um recurso.

Exemplo:

PATCH /produtos/10

Significa:

Servidor, altere apenas alguns campos do produto 10.

O corpo poderia ser:

{
  "preco": 4999.00
}

Nesse caso, apenas o preço seria alterado, sem necessidade de enviar todos os dados do produto.

DELETE

O método DELETE é usado para remover um recurso.

Exemplo:

DELETE /produtos/10

Significa:

Servidor, remova o produto de código 10.

Em sistemas reais, o DELETE pode apagar fisicamente um registro ou apenas marcar como inativo, dependendo da regra de negócio.

8. O que é frontend?

Frontend é a parte da aplicação que o usuário vê e usa.

É a interface.

Normalmente envolve:

HTML
CSS
JavaScript

O HTML define a estrutura da página.

O CSS define a aparência visual.

O JavaScript adiciona comportamento e interação.

Por exemplo, quando você vê um botão, um menu, um formulário, uma tabela, uma mensagem de erro ou uma tela de login, está olhando para o frontend.

O frontend também pode conversar com o backend usando requisições HTTP.

Um exemplo simples com JavaScript seria:

fetch("https://api.meusite.com/produtos")
  .then(resposta => resposta.json())
  .then(dados => console.log(dados));

Esse código pede dados ao backend e depois trata a resposta como JSON.

O frontend não deve ser confundido com “design bonito”. Ele também envolve lógica, validação, consumo de API, estado da tela, acessibilidade, performance e experiência do usuário.

9. O que é backend?

Backend é a parte da aplicação que roda no servidor.

Ele é responsável por receber requisições, aplicar regras de negócio, acessar banco de dados e devolver respostas.

Exemplos de tecnologias backend:

Java + Spring Boot
PHP + Laravel
Python + Django
Node.js + Express
C# + ASP.NET
Ruby + Rails
Go

Apesar das diferenças de sintaxe, a lógica geral é muito parecida.

Um backend normalmente faz coisas como:

Receber requisição
Validar dados
Verificar permissões
Executar regra de negócio
Consultar banco de dados
Salvar informações
Gerar resposta
Retornar status code correto

Imagine um sistema de loja.

Quando o usuário tenta comprar um produto, o backend precisa verificar:

O produto existe?
Há estoque disponível?
O usuário está logado?
O pagamento foi aprovado?
O endereço de entrega é válido?
O pedido pode ser criado?

Essa lógica não deve ficar apenas no frontend, porque o frontend pode ser manipulado pelo usuário. As regras importantes precisam estar no backend.

Por isso, em muitos sistemas, o backend é considerado o cérebro da aplicação.

10. O que é banco de dados?

Banco de dados é onde o sistema armazena informações.

Exemplos de dados que podem ser guardados:

Usuários
Produtos
Pedidos
Pagamentos
Comentários
Arquivos
Configurações
Permissões
Histórico de acesso
Logs

Existem bancos relacionais, como:

MySQL
PostgreSQL
Oracle
SQL Server
SQLite

Também existem bancos NoSQL, como:

MongoDB
Redis
DynamoDB
Cassandra

Um banco relacional costuma organizar dados em tabelas.

Por exemplo, em uma loja virtual, poderíamos ter tabelas como:

usuarios
produtos
pedidos
itens_pedido
pagamentos
enderecos

Cada tabela guarda um tipo de informação.

Já bancos NoSQL podem organizar dados de outras formas, como documentos, chave-valor, colunas ou grafos.

Neste começo da trilha, o mais importante é entender isto:

Sistema sem banco de dados geralmente esquece tudo quando reinicia.

Se uma aplicação guarda dados apenas na memória, esses dados podem desaparecer quando o servidor reinicia. O banco existe justamente para manter as informações armazenadas de forma persistente.

11. O que é JSON?

JSON significa JavaScript Object Notation.

É um formato de dados muito usado para comunicação entre frontend e backend.

Um exemplo de JSON:

{
  "id": 1,
  "nome": "Michel",
  "email": "michel@email.com"
}

Uma lista em JSON poderia ser assim:

[
  {
    "id": 1,
    "titulo": "Estudar HTTP",
    "concluida": false
  },
  {
    "id": 2,
    "titulo": "Criar primeira API",
    "concluida": true
  }
]

O JSON é popular porque é simples de ler, fácil de gerar e funciona bem em várias linguagens.

Um backend em Java pode gerar JSON.

Um backend em PHP pode gerar JSON.

Um backend em Python pode gerar JSON.

Um frontend em JavaScript pode receber JSON e transformar esses dados em elementos visuais na tela.

Por isso, JSON virou um dos formatos mais usados em APIs modernas.

12. O fluxo completo de uma aplicação web

Agora vamos juntar tudo.

Imagine uma aplicação simples de tarefas.

O usuário acessa a tela para ver suas tarefas.

O fluxo completo pode ser:

1. Usuário acessa a página
2. O navegador consulta o DNS
3. O navegador encontra o servidor
4. O navegador baixa HTML, CSS e JavaScript
5. O frontend é carregado na tela
6. O frontend faz uma requisição para a API
7. O backend recebe a requisição
8. O backend verifica quem é o usuário
9. O backend consulta o banco de dados
10. O banco devolve as tarefas
11. O backend transforma os dados em JSON
12. O backend devolve uma resposta HTTP
13. O frontend recebe o JSON
14. O frontend monta a lista de tarefas
15. O usuário vê as tarefas na tela

Esse é o coração de praticamente todo sistema web moderno.

Mesmo sistemas grandes seguem uma lógica parecida. O que muda é a quantidade de camadas, regras, serviços, integrações e cuidados técnicos envolvidos.

13. Exemplo prático: sistema de tarefas

Imagine que o usuário abre uma tela chamada “Minhas tarefas”.

Por trás disso, a conversa poderia ser assim:

Frontend:
"Quero listar as tarefas do Michel."

Backend:
"Vou verificar se o Michel está autenticado."

Backend:
"Agora vou buscar as tarefas dele no banco."

Banco de dados:
"Aqui estão as tarefas encontradas."

Backend:
"Vou transformar isso em JSON."

Frontend:
"Vou exibir essas tarefas na tela."

A resposta do backend poderia ser:

[
  {
    "id": 1,
    "titulo": "Estudar HTTP",
    "concluida": false
  },
  {
    "id": 2,
    "titulo": "Criar primeira API",
    "concluida": true
  }
]

O frontend recebe esse JSON e transforma os dados em uma interface:

[ ] Estudar HTTP
[x] Criar primeira API

Perceba que o usuário não vê o banco de dados, não vê a query SQL, não vê o servidor e não vê o JSON bruto.

Ele vê apenas a tela final.

Mas o desenvolvedor precisa entender todas as partes que fizeram essa tela aparecer.

14. Exemplo prático: fluxo de login

Agora imagine o fluxo de login.

O usuário digita email e senha e clica em “Entrar”.

O fluxo pode ser:

1. Usuário digita email e senha
2. Frontend captura os dados do formulário
3. Frontend envia uma requisição POST para o backend
4. Backend recebe email e senha
5. Backend valida se os campos foram preenchidos
6. Backend procura o usuário no banco
7. Backend verifica se a senha está correta
8. Backend gera uma resposta de sucesso ou erro
9. Frontend recebe a resposta
10. Frontend mostra a próxima tela ou uma mensagem de erro

A requisição poderia ser:

POST /login
Content-Type: application/json

Com o corpo:

{
  "email": "usuario@email.com",
  "senha": "123456"
}

Se os dados estiverem corretos, o backend poderia responder:

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

{
  "mensagem": "Login realizado com sucesso"
}

Se a senha estiver errada, poderia responder:

HTTP/1.1 401 Unauthorized
Content-Type: application/json

{
  "erro": "Email ou senha inválidos"
}

Esse exemplo mostra por que HTTP, backend, banco de dados, JSON e status codes trabalham juntos.

15. Diferença entre página web e API

Um ponto importante para iniciantes é entender a diferença entre uma página web e uma API.

Uma página web normalmente devolve HTML para ser exibido no navegador.

Exemplo:

GET /sobre

Resposta:

<h1>Sobre o site</h1>
<p>Bem-vindo ao nosso projeto.</p>

Já uma API normalmente devolve dados, muitas vezes em JSON.

Exemplo:

GET /api/produtos

Resposta:

[
  {
    "id": 1,
    "nome": "Mouse"
  },
  {
    "id": 2,
    "nome": "Teclado"
  }
]

A página é feita para o usuário ver.

A API é feita para outro sistema, frontend, aplicativo mobile ou serviço consumir.

Em muitos sistemas modernos, o frontend é separado do backend. O frontend mostra a interface e o backend expõe APIs para fornecer os dados.

16. O que é deploy?

Deploy é o processo de colocar uma aplicação no ar.

Quando você desenvolve no seu computador, a aplicação está em ambiente local. Apenas você consegue acessar.

Quando faz deploy, você envia a aplicação para um servidor ou plataforma de hospedagem, para que outras pessoas possam usar.

Exemplos de lugares onde uma aplicação pode ser publicada:

Servidor VPS
Hospedagem compartilhada
Cloud
Docker
Kubernetes
Vercel
Netlify
Render
Railway
AWS
Azure
Google Cloud
HostGator

O deploy faz parte da vida real do desenvolvedor.

Não basta o sistema funcionar no seu computador. Ele precisa funcionar em um ambiente acessível, seguro, estável e configurado corretamente.

17. Onde entram segurança e performance?

Quando estamos começando, é comum pensar apenas no fluxo básico:

frontend → backend → banco

Mas sistemas reais precisam de mais cuidados.

Na segurança, entram temas como:

HTTPS
Autenticação
Autorização
Proteção contra SQL Injection
Proteção contra XSS
Validação de dados
Controle de sessão
Tokens
Cookies seguros
Permissões

Na performance, entram temas como:

Cache
Compressão
Otimização de imagens
Consultas eficientes ao banco
Paginação
CDN
Balanceamento de carga
Índices no banco de dados

Você não precisa dominar tudo isso na primeira aula.

Mas precisa saber que uma aplicação real não é apenas “uma tela bonita com um banco por trás”. Ela envolve várias camadas de responsabilidade.

18. Erros comuns de iniciantes

Ao aprender desenvolvimento web, muitos iniciantes confundem alguns conceitos.

Veja os erros mais comuns.

Achar que frontend e backend são a mesma coisa

Frontend é a parte visual e interativa que roda no navegador.

Backend é a parte que roda no servidor e aplica as regras do sistema.

Eles se comunicam, mas não são a mesma coisa.

Achar que banco de dados é o backend

O banco de dados guarda informações.

O backend usa o banco, mas também faz validações, regras de negócio, segurança, autenticação e montagem de respostas.

Achar que JSON é banco de dados

JSON é um formato de troca de dados.

Ele pode representar informações, mas não é necessariamente um banco.

Usar GET para tudo

GET deve ser usado para buscar informações.

Para criar, atualizar ou remover dados, usamos outros métodos, como POST, PUT, PATCH e DELETE.

Ignorar status codes

Status codes ajudam a entender o resultado da requisição.

Um bom desenvolvedor não devolve sempre 200 para tudo. Ele usa códigos adequados para sucesso, erro de validação, falta de autenticação, recurso não encontrado e erro interno.

Achar que funcionar localmente é suficiente

Uma aplicação pode funcionar no computador do desenvolvedor e falhar no servidor.

Por isso, deploy, configuração, ambiente, variáveis, banco, permissões e logs também fazem parte do processo.

19. Conceito-chave da lição

Um fullstack de verdade não pensa apenas em código.

Ele pensa no caminho completo:

Tela
Requisição
Servidor
Backend
Regra de negócio
Banco de dados
Resposta
Status code
Segurança
Deploy
Manutenção

Dominar fullstack não é decorar várias linguagens.

É entender como os sistemas funcionam por baixo.

Depois que você entende esse fluxo, aprender Java, PHP, Python, JavaScript, Spring Boot, Laravel, Django, Node.js ou qualquer outra tecnologia fica muito mais fácil.

A linguagem muda.

O fluxo principal continua.

20. Resumo da lição

Nesta lição, você aprendeu que:

Frontend é a interface.
Backend é o cérebro.
Banco de dados é a memória.
HTTP é a conversa.
DNS ajuda a encontrar o servidor.
JSON é um formato comum de mensagem.
Status code informa o resultado da requisição.
Deploy é colocar a aplicação no ar.

Também aprendeu que uma aplicação web funciona como uma sequência de comunicação:

Usuário acessa o site
↓
Navegador envia requisição
↓
Servidor recebe o pedido
↓
Backend processa a regra
↓
Banco de dados pode ser consultado
↓
Backend devolve resposta
↓
Frontend exibe o resultado

Esse é um dos fundamentos mais importantes para quem quer aprender desenvolvimento web de verdade.

Exercício prático

Crie um arquivo chamado:

licao-2-como-a-web-funciona.md

Dentro dele, responda com suas próprias palavras:

1. O que acontece quando você acessa um site?
2. O que é DNS?
3. O que é HTTP?
4. Qual a diferença entre HTTP e HTTPS?
5. O que é frontend?
6. O que é backend?
7. O que é banco de dados?
8. O que é JSON?
9. Qual a diferença entre GET e POST?
10. Para que servem os status codes?
11. O que acontece em um fluxo de login?
12. Por que um fullstack precisa entender o caminho completo?

Mini desafio

Explique este fluxo como se estivesse ensinando uma pessoa totalmente leiga:

Usuário clica em "Entrar"
↓
Frontend envia email e senha
↓
Backend recebe os dados
↓
Backend valida os campos
↓
Backend consulta o banco de dados
↓
Backend verifica se a senha está correta
↓
Backend devolve sucesso ou erro
↓
Frontend mostra a próxima tela ou uma mensagem de erro

Depois, tente responder:

Onde entra o HTTP?
Onde entra o JSON?
Onde entra o banco de dados?
Onde entra o status code?
Onde entra o backend?
Onde entra o frontend?

Se você conseguir explicar esse fluxo com clareza, já deu um passo enorme para entender desenvolvimento web.

Conclusão

Entender como a web funciona é uma das bases mais importantes para qualquer desenvolvedor.

Antes de aprender frameworks, bibliotecas, arquitetura avançada ou microsserviços, você precisa compreender o caminho básico de uma aplicação: o usuário acessa uma interface, o navegador envia uma requisição, o servidor processa o pedido, o backend aplica regras, o banco pode ser consultado e uma resposta volta para a tela.

Esse fluxo aparece em sites simples, sistemas corporativos, lojas virtuais, redes sociais, APIs, aplicativos mobile e plataformas modernas.

A partir de agora, quando você acessar um site, tente imaginar o que está acontecendo por trás. Pense no navegador, no DNS, no servidor, no backend, no banco, na resposta, no JSON e no status code.

Quando esse caminho fica claro, a programação deixa de parecer mágica e começa a fazer sentido.

Curso de Programação Fullstack – DevMedia