T
http rfc9110 rest web-architecture standards

Semântica HTTP Explicada: Domine a RFC 9110 para o Desenvolvimento Web Moderno

Entenda o núcleo da web. Um guia sobre a RFC 9110, cobrindo métodos HTTP, códigos de status e semântica de cabeçalhos.

2026-04-11

Semântica HTTP Explicada: Domine a RFC 9110 para o Desenvolvimento Web Moderno

Em 2022, o IETF publicou a RFC 9110, um documento monumental que tornou obsoletas várias RFCs antigas (como a RFC 7231) para se tornar a autoridade definitiva sobre a Semântica HTTP. Embora o HTTP/2 e o HTTP/3 tenham mudado a forma como os dados são transportados, a semântica — o significado dos métodos, códigos de status e cabeçalhos — continua sendo a base da web.

O que é a RFC 9110 (Semântica HTTP)?

A RFC 9110 define a arquitetura comum do Protocolo de Transferência de Hipertexto (HTTP). Ela é independente da versão do protocolo (HTTP/1.1, HTTP/2 ou HTTP/3). Se você quiser saber o que um 403 Forbidden realmente significa ou como uma solicitação POST deve se comportar em comparação com um PUT, a RFC 9110 é a fonte da verdade.

Ela fornece um vocabulário consistente para:

  • Recursos e Identificadores de Recursos Uniformes (URIs).
  • Mensagens (Solicitações e Respostas).
  • Métodos (GET, POST, etc.).
  • Códigos de status (200, 404, etc.).
  • Campos de cabeçalho.

Princípios Core da Semântica HTTP

1. Métodos de Solicitação e Idempotência

Um dos conceitos mais importantes na RFC 9110 é a distinção entre métodos Seguros (Safe) e Idempotentes.

Método Seguro Idempotente Descrição
GET Sim Sim Recupera dados sem efeitos colaterais.
HEAD Sim Sim Igual ao GET, mas não retorna corpo.
PUT Não Sim Substitui um recurso; repetir não tem efeito adicional.
DELETE No Sim Remove um recurso.
POST Não Não Processa dados; múltiplas solicitações podem criar múltiplos recursos.

2. Classes de Códigos de Status

A RFC 9110 organiza os códigos de status em cinco classes:

  • 1xx (Informativo): Solicitação recebida, continuando o processo.
  • 2xx (Sucesso): A ação foi recebida, compreendida e aceita com sucesso.
  • 3xx (Redirecionamento): Mais ações precisam ser tomadas para concluir a solicitação.
  • 4xx (Erro do Cliente): A solicitação contém sintaxe incorreta ou não pode ser atendida.
  • 5xx (Erro do Servidor): O servidor falhou ao atender uma solicitação aparentemente válida.

Cenários de Aplicação Prática

Design de APIs RESTful

Seguir a RFC 9110 garante que sua API seja "descoberta" e se comporte como esperado pelos clientes HTTP padrão e caches. Por exemplo, usar 201 Created após um POST bem-sucedido em vez de um genérico 200 OK.

Otimização de Cache

A RFC 9110 define como os cabeçalhos Vary, ETag e Last-Modified funcionam. A implementação correta permite que CDNs e navegadores armazenem dados em cache com eficiência, reduzindo a carga do servidor.

Negociação de Conteúdo

O protocolo permite que um cliente solicite um formato específico (ex: Accept: application/json) e o servidor responda com a melhor representação disponível.

Comparação: RFC 7231 vs. RFC 9110

A RFC 9110 não mudou fundamentalmente como o HTTP funciona, mas melhorou a documentação significativamente:

  • Consolidação: Mesclou a semântica de vários documentos em um só.
  • Clareza: Esclareceu pontos ambíguos sobre conteúdo parcial (solicitações Range) e autenticação.
  • Versão: Separa explicitamente o "quê" (Semântica) do "como" (HTTP/1.1 vs HTTP/3).

FAQ

P: A RFC 9110 é apenas para HTTP/1.1?
R: Não. A RFC 9110 define a semântica que se aplica a todas as versões do HTTP, incluindo HTTP/2 e HTTP/3.

P: Qual é a diferença entre POST e PUT?
R: De acordo com a RFC 9110, PUT é idempotente (substitui o recurso em uma URI específica), enquanto POST não é (ele envia dados para serem processados pelo recurso).

P: Quando devo usar um 403 em vez de um 401?
R: Use 401 Unauthorized quando a autenticação for necessária e falhar ou não for fornecida. Use 403 Forbidden quando o servidor entender a solicitação, mas se recusar a autorizá-la (mesmo com credenciais válidas).

Ferramentas Relacionadas

Voltar ao blog