Comunicação Web

Prévia do material em texto

Fundamentos do HTTP 
para Backend
Prof. Júlio César Andrade
Tema da aula:
Introdução
A maior parte da comunicação web é 
estruturada em torno do protocolo HTTP 
(Hypertext Transfer Protocol). O HTTP 
define como os dados são transferidos 
entre um cliente (como um navegador 
web) e um servidor (como um site).
2
Introdução
O que é HTTP?
HTTP é a sigla para Hypertext Transfer 
Protocol, ou Protocolo de Transferência de 
Hipertexto.
3
Introdução
Características do HTTP
● Protocolo da camada de aplicação;
● Funciona baseado na troca de 
requisição resposta;
● Cabeçalho das mensagens é texto 
puro (não binário);
● Não orientado a conexões.
4
Introdução
Baseia-se no modelo cliente-servidor:
A comunicação é baseado 
em solicitações (requests) 
feitas por clientes e respostas 
(responses) fornecidas por 
servidores. 
5
Quem são esses clientes?
6
Como o HTTP se 
encaixa no 
desenvolvimento 
backend?
7
8
HTTP no desenvolvimento backend
O frontend (navegador ou app) e o backend (servidor) se comunicam através de requisições HTTP.
Fluxo típico:
1⃣ O frontend faz uma requisição HTTP (GET, POST, etc.).
2⃣ O backend processa a requisição e acessa bancos de dados ou outras fontes de informação.
3⃣ O backend retorna uma resposta HTTP, geralmente em JSON ou HTML.
4⃣ O frontend exibe os dados ou realiza alguma ação com a resposta.
9
HTTP/1.1 – Conexões Persistentes
Antes do HTTP/1.1, cada requisição HTTP 
exigia uma nova conexão TCP com o 
servidor. 
No HTTP/1.1, a conexão passa a ser 
reutilizada para múltiplas requisições, 
evitando o tempo gasto na abertura e 
fechamento de conexões.
10
HTTP/1.1 – Conexões Persistentes
Como funciona?
● O navegador faz uma requisição para carregar a página.
● Mantém a conexão aberta para carregar outros recursos (CSS, 
imagens, scripts).
● Cada requisição ainda precisa esperar a anterior ser concluída antes 
de ser processada (não simultânea).
11
Problema: Se um recurso demorar para ser 
carregado, ele bloqueia as requisições seguintes.
HTTP/2 – Multiplexação
O que é?
A multiplexação permite que múltiplas requisições sejam 
enviadas ao mesmo tempo pela mesma conexão TCP.
12
HTTP/2 – Multiplexação
Como funciona?
● O navegador pode enviar várias requisições simultaneamente na mesma conexão.
● Cada requisição recebe uma prioridade e não precisa esperar outras serem 
concluídas.
● Se um recurso demorar para carregar, ele não bloqueia os demais.
13
Benefício: Permite carregar páginas muito mais rápido, pois os 
recursos não ficam presos esperando um de cada vez.
HTTP/3 – A Evolução do HTTP
O HTTP/3 substitui o TCP pelo protocolo QUIC, tornando 
as conexões mais rápidas, seguras e eficientes, 
especialmente em redes instáveis.
14
HTTP/3 – A Evolução do HTTP
Principais Vantagens do HTTP/3
✅ Menor latência: QUIC elimina o atraso do handshake do TCP, acelerando a 
conexão inicial.
✅ Sem bloqueio de cabeçalhos: Cada requisição é independente, evitando 
bloqueios de pacotes perdidos (problema do HTTP/2).
✅ Mais eficiente em redes instáveis: Melhor desempenho em redes móveis e 
conexões com perda de pacotes.
✅ Segurança integrada: QUIC já inclui criptografia TLS 1.3, tornando as 
conexões seguras por padrão.
15
Mais características do HTTP
Baseado em texto
Apesar de poder transportar dados binários, as 
mensagens HTTP (requisições e respostas) são 
fundamentalmente baseadas em texto, facilitando a 
leitura e o debug por humanos.
16
Mais características do HTTP
Sem estado (stateless)
● O HTTP por si só não mantém estado entre 
transações. 
● Cada requisição é independente, o que 
significa que informações sobre conexões 
anteriores não são mantidas.
17
18
Como se faz sessão então?
Como Funciona uma Sessão HTTP
Lembrando:
HTTP é Stateless:
● O protocolo HTTP não mantém estado entre 
requisições, ou seja, cada requisição é independente.
19
Como Funciona uma Sessão HTTP
Uso de Cookies para Sessões:
● O servidor envia um cookie de sessão para 
o cliente na resposta HTTP.
● O cliente armazena esse cookie e o envia em 
todas as requisições subsequentes.
20
O que são Cookies?
Cookies são pequenos arquivos de texto 
armazenados no navegador do usuário para 
guardar informações entre requisições 
HTTP.
21
Tipos de Cookies:
✅ Cookies de Sessão: Temporários, expirando ao fechar o 
navegador.
✅ Cookies Persistentes: Mantêm dados por um período 
definido.
✅ Cookies de Terceiros: Criados por domínios externos (ex: 
anúncios, rastreamento).
✅ Cookies Seguros: Usados apenas em conexões HTTPS.
22
Para que servem?
● Autenticação (ex: manter o usuário logado).
● Preferências do Usuário (ex: idioma, tema).
● Rastreamento e Análises (ex: Google 
Analytics).
23
Como Funciona uma Sessão HTTP
 Sessões no Servidor:
● O servidor mantém um ID de sessão associado a dados do 
usuário (autenticação, carrinho de compras, etc.).
● Esse ID de sessão é salvo em memória, banco de dados ou 
cache (ex: Redis).
24
Como Funciona uma Sessão HTTP
Exemplo de Processo de Sessão:
1⃣ Cliente faz login → Servidor gera um ID de sessão.
2⃣ Servidor retorna um cookie de sessão (Set-Cookie: 
session_id=12345).
3⃣ Cliente inclui esse cookie em todas as requisições seguintes 
(Cookie: session_id=12345).
4⃣ Servidor usa o session_id para identificar o usuário autenticado.
25
Como Funciona uma Sessão HTTP
Alternativas Modernas:
● JWT (JSON Web Token): Em vez de armazenar sessões no 
servidor, o cliente recebe um token assinado que contém os 
dados do usuário.
● OAuth/OpenID Connect: Utilizado para autenticação via 
terceiros (Google, Facebook, etc.).
26
Mensagens HTTP
27
As mensagens HTTP são a base da comunicação entre um 
cliente (navegador web, aplicativo) e um servidor web. 
Requisição Resposta
28
Introdução a mensagens HTTPS
Linha de Requisição
Cabeçalhos
Corpo da Mensagem
Introdução a mensagens HTTPS
Elas são compostas por linhas de texto e podem ser divididas em 3 partes 
principais:
29
Requisições HTTP
30
Estrutura de uma Requisição HTTP
Uma requisição HTTP é composta por três partes principais:
1⃣ Linha de Requisição – Define o método, URL e versão do protocolo.
2⃣ Cabeçalhos (Headers) – Contêm informações adicionais sobre a requisição.
3⃣ Corpo (Body) – Transporta dados (usado em POST, PUT, etc.).
31
Linha de Requisição
A primeira linha da requisição contém:
32
 
● Método HTTP: Indica a ação desejada (como GET e POST)
● URI: Identifica o recurso solicitado (caminho do arquivo ou página)
● Versão do HTTP: Indica a versão do protocolo utilizada
Linha de Requisição
GET → Método HTTP.
/api/usuarios/1 → Caminho do recurso solicitado.
HTTP/1.1 → Versão do protocolo HTTP.
33
GET /api/usuarios/1 HTTP/1.1
💡 Mais a frente você irá conhecer outros métodos e função de cada um deles.
34
Cabeçalhos (Headers)
Os headers fornecem informações sobre a requisição, como tipo de conteúdo, 
autenticação e configuração do cliente.
35
Cabeçalhos (Headers)
Principais headers:
● Host → Define o domínio da requisição.
● User-Agent → Identifica o cliente (navegador, app, etc.).
● Authorization → Contém credenciais de autenticação.
● Content-Type → Define o formato dos dados no corpo (JSON, XML, etc.).
● Accept → Especifica os formatos aceitos na resposta (application/json, 
text/html).
● Connection → Define se a conexão deve ser mantida aberta (keep-alive) ou 
fechada (close).
● Content-Length → Define o tamanho do corpo da requisição.
36
Corpo da Requisição (Body)
● É opcional;
● Usado em métodos como POST, PUT e PATCH para enviar 
dados ao servidor.
37
POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 57
{"username": "usuario", "password": "senha123"}
38
Atenção!
O corpo da mensagem é separado dos 
cabeçalhos por uma linha vazia.
Exemplo de requisição
39
Respostas HTTP
40
Estrutura de uma Resposta HTTP
Uma resposta HTTP é composta por três partes principais:1⃣ Linha de Status – Indica o status da requisição.
2⃣ Cabeçalhos (Headers) – Contêm informações adicionais sobre a 
resposta.
3⃣ Corpo (Body) – Contém os dados enviados ao cliente (geralmente em 
formato JSON ou HTML).
41
Linha de status: Respostas
● Versão do HTTP: Indica a versão do protocolo
● Código de Status: Indica o resultado da requisição
● Mensagem de Razão: Uma breve descrição do código de status.
HTTP/1.1 200 OK
💡 Mais a frente você irá conhecer outros códigos e função de cada um deles.
42
Estrutura de uma Resposta HTTP
Cabeçalhos (Headers) da Resposta
43
Os headers da resposta fornecem informações adicionais sobre a resposta, como 
tipo de conteúdo, cache, segurança, etc.
44
Cabeçalhos (Headers) da Resposta
Principais headers de resposta:
● Content-Type → Especifica o tipo de conteúdo (por exemplo, application/json, 
text/html).
● Content-Length → Informa o tamanho do corpo da resposta.
● Cache-Control → Controla o cache da resposta (por exemplo, no-cache, 
max-age=3600).
● Server → Informa qual servidor processou a requisição (por exemplo, nginx, Apache).
● Set-Cookie → Envia um cookie para o cliente.
Corpo (Body) da Resposta
O corpo da resposta contém os dados 
solicitados ou uma mensagem explicativa (se 
houver). O corpo pode ser JSON, HTML, XML, 
texto ou qualquer outro formato de mídia.
45
46
Métodos HTTP
47
GET
 Objetivo: Recuperar informações de um recurso.
● Descrição: O método GET é usado para buscar dados do servidor. Ele não deve 
alterar o estado do recurso (é idempotente e seguro).
● Exemplo de Uso:
○ Buscar detalhes de um usuário.
○ Exemplo: GET /api/usuarios/1
Características:
● Seguro: Não altera os dados no servidor.
● Idempotente: Repetir a requisição várias vezes retorna o mesmo resultado.
● Sem corpo (Body): A requisição não possui corpo de dados.
48
49
POST
Objetivo: Enviar dados ao servidor para criar um novo recurso.
● Descrição: O método POST é usado para criar ou submeter dados no 
servidor. Geralmente, é utilizado para criar novos registros ou enviar 
formulários.
● Exemplo de Uso:
○ Criar um novo usuário.
○ Exemplo: POST /api/usuarios (com dados no corpo).
🔑 Características:
● Pode ter corpo (Body): Contém dados a serem enviados ao servidor, como 
JSON ou XML.
50
51
PUT
Objetivo: Substituir ou atualizar um recurso existente.
● Descrição: O método PUT é usado para substituir ou atualizar completamente um recurso 
existente no servidor. A URL especifica o recurso a ser atualizado.
● Exemplo de Uso:
○ Atualizar as informações de um usuário.
○ Exemplo: PUT /api/usuarios/1 (com novos dados no corpo).
Características:
● Idempotente: A repetição da requisição não altera o resultado (o recurso permanece o 
mesmo).
● Substituição completa: O recurso é substituído por completo, não sendo possível enviar 
apenas partes dos dados.
52
53
PATCH
Objetivo: Atualizar parcialmente um recurso.
● Descrição: O método PATCH é usado para atualizar parcialmente um recurso, ou 
seja, modificar apenas uma parte de um recurso sem substituí-lo completamente.
● Exemplo de Uso:
○ Atualizar o endereço de um usuário.
○ Exemplo: PATCH /api/usuarios/1 (com dados parciais no corpo).
Características:
● Não idempotente: Se repetido, pode ter resultados diferentes (dependendo do que é 
alterado).
● Parcial: Apenas partes do recurso são modificadas.
54
55
DELETE
Objetivo: Remover um recurso existente.
● Descrição: O método DELETE é usado para remover um recurso do servidor.
● Exemplo de Uso:
○ Excluir um usuário.
○ Exemplo: DELETE /api/usuarios/1
Características:
● Idempotente: Repetir a requisição não altera o estado do servidor (o recurso 
continua ausente).
● Sem corpo (Body): Normalmente, não há corpo de dados na requisição.
56
57
HEAD
Objetivo: Recuperar os cabeçalhos de uma resposta sem o corpo.
● Descrição: O método HEAD é similar ao GET, mas a resposta não inclui o corpo, 
apenas os cabeçalhos. É útil para verificar metadados de um recurso, como a data 
de modificação ou o tamanho.
● Exemplo de Uso:
○ Verificar informações de um recurso sem retornar o corpo.
○ Exemplo: HEAD /api/usuarios/1
Características:
● Seguro e idempotente.
● Sem corpo (Body): Não retorna dados no corpo da resposta.
58
59
OPTIONS
Objetivo: Obter os métodos HTTP suportados por um recurso.
● Descrição: O método OPTIONS é usado para obter informações sobre quais métodos 
HTTP o servidor permite em um recurso específico.
● Exemplo de Uso:
○ Verificar quais métodos podem ser usados para interagir com um recurso.
○ Exemplo: OPTIONS /api/usuarios
Características:
● Idempotente.
● Sem corpo (Body): A resposta contém os métodos permitidos.
60
Exemplo de OPTIONS
61
Códigos de 
status HTTP
62
Códigos de status HTTP
● Os códigos de status HTTP fornecem 
informações sobre o resultado de uma 
requisição;
● Ajudam tanto o cliente quanto o servidor a 
entender o sucesso ou falha da operação, 
e se alguma ação adicional é necessária. 
● Eles são essenciais para o 
desenvolvimento e manutenção de APIs e 
sistemas web!
63
Códigos de status HTTP
2xx: Sucesso
Esses códigos indicam que a requisição foi bem-sucedida e o servidor processou a 
requisição com êxito.
● 200 OK: A requisição foi bem-sucedida e o servidor está retornando a resposta.
● 201 Created: O recurso foi criado com sucesso. Geralmente, retorna um recurso 
novo (por exemplo, um novo usuário ou item) após uma requisição POST.
● 202 Accepted: A requisição foi recebida, mas ainda não foi processada. A 
operação pode ser concluída posteriormente.
● 204 No Content: A requisição foi bem-sucedida, mas não há conteúdo a ser 
retornado. Frequentemente utilizado em DELETE ou PUT que não necessitam de 
resposta.
64
Códigos de status HTTP
3xx: Redirecionamento
Esses códigos indicam que o cliente precisa fazer mais alguma ação para completar a requisição.
● 301 Moved Permanently: O recurso solicitado foi movido permanentemente para uma nova 
URL. O cliente deve usar a nova URL em futuras requisições.
● 302 Found: O recurso solicitado foi temporariamente movido para uma nova URL.
● 304 Not Modified: O recurso não foi modificado desde a última requisição, portanto o 
conteúdo não precisa ser transferido novamente.
● 308 Permanent Redirect: O cliente deve fazer a requisição para uma nova URL 
permanentemente.
65
Códigos de status HTTP
4xx: Erro do Cliente
Esses códigos indicam que houve um erro por parte do cliente, ou seja, a requisição não pôde ser 
processada devido a informações incorretas ou inválidas fornecidas pelo cliente.
● 400 Bad Request: A requisição do cliente está malformada ou contém parâmetros inválidos.
● 401 Unauthorized: O cliente precisa se autenticar para acessar o recurso.
● 403 Forbidden: O cliente está autenticado, mas não tem permissão para acessar o recurso.
● 404 Not Found: O recurso solicitado não foi encontrado no servidor.
● 405 Method Not Allowed: O método HTTP utilizado não é permitido para o recurso solicitado.
● 408 Request Timeout: O servidor não recebeu a requisição completa dentro do tempo limite.
● 410 Gone: O recurso solicitado foi removido permanentemente e não estará mais disponível.
66
Códigos de status HTTP
5xx: Erro do Servidor
Esses códigos indicam que o servidor encontrou um erro ao tentar processar a requisição. O erro não é culpa do 
cliente.
● 500 Internal Server Error: Ocorreu um erro genérico no servidor e a requisição não pôde ser completada.
● 501 Not Implemented: O servidor não suporta o método HTTP utilizado na requisição.
● 503 Service Unavailable: O servidor não está disponível temporariamente devido a manutenção ou 
sobrecarga.
67
HTTPS
68
HTTPS
Trata-se do mesmo protocolo HTTP, mas 
com uma camada a mais de segurança 
que protege as transferências de dados 
entre cliente e servidor.
69
Comunicação entre cliente 
e servidor é criptografada.
70
71
Criptografia SSL/TLS
● O HTTPS utiliza SSL (Secure Sockets Layer) ou, mais comumente hoje, TLS (TransportLayer Security) para criptografar os dados transmitidos entre o cliente e o servidor.
● A criptografia protege os dados, tornando-os ilegíveis para qualquer pessoa que tente 
interceptar a comunicação. 
72
Certificados SSL/TLS:
● Para estabelecer uma conexão HTTPS, o servidor 
precisa de um certificado SSL/TLS, que serve para 
verificar sua identidade.
● O certificado é emitido por uma Autoridade 
Certificadora (CA) confiável, que garante que o 
servidor é legítimo e que a comunicação será segura.
● Quando o cliente (navegador) se conecta ao servidor via 
HTTPS, ele verifica a validade do certificado e, se for 
válido, a conexão segura é estabelecida.
73
Estabelecimento de Conexão Segura (Handshaking):
● O processo começa com o navegador fazendo uma requisição ao 
servidor para uma conexão segura.
● O servidor envia seu certificado SSL/TLS, e o navegador valida a 
autenticidade do certificado.
● Em seguida, o navegador e o servidor negociam as chaves 
criptográficas para a sessão de comunicação, utilizando algoritmos 
seguros.
● Após a verificação do certificado e a troca de chaves, uma 
comunicação criptografada começa, e os dados podem ser trocados 
de maneira segura.
74
75
Obrigado! Até a próxima aula.
76
Obrigado!