Resumo

  • A RFC 9110 chama o token do método de fonte principal da semântica da requisição: ele mostra o objetivo do cliente, enquanto cada recurso decide se reconhece, implementa e admite esse método.
  • Safe trata do que o cliente pediu, não da inexistência de todo efeito colateral. Idempotent trata do efeito pretendido ao repetir, não de respostas, registros ou consequências externas idênticas.
  • O recibo completo une método, alvo, principal autenticado, política de autorização, precondição, incerteza sobre a primeira tentativa, idempotência de aplicação, repetição, resposta, estado observado e efeitos a jusante.

GET, PUT e DELETE parecem ordens. No protocolo, são antes declarações públicas de intenção. Um cache pode diferenciar leitura e mudança. Um gateway pode aplicar limites. Um cliente pode avaliar a recuperação depois de perder uma resposta. Nenhum deles precisa conhecer a implementação inteira.

O perigo começa quando essa visibilidade é convertida em autoridade. Um servidor pode entender PUT e não oferecê-lo naquele recurso. Pode oferecê-lo e negar aquele usuário. Pode autorizar o usuário e rejeitar uma versão antiga. Pode efetivar a mudança e perder a resposta. O verbo, sozinho, não distingue esses estados.

A interface uniforme compartilha significado, não poder

Segundo a RFC 9110, o método indica a finalidade da requisição e o resultado que o cliente espera considerar bem-sucedido. GET solicita uma representação atual. PUT solicita a criação ou substituição do estado representado no alvo. DELETE pede que se remova a associação do URI com sua funcionalidade atual; não promete apagar toda cópia física.

Um método padronizado deve preservar sua semântica em recursos diferentes. Essa uniformidade torna o comportamento visível e reutilizável. Cabe a cada recurso, porém, decidir se o método existe e é permitido. Um método desconhecido ou não implementado pede 501. Um método conhecido, mas não suportado pelo alvo, pede 405 e um Allow com os métodos atuais.

Allow descreve capacidade, não pessoas autorizadas. Um documento pode aceitar PUT e ainda exigir um editor. Uma coleção pode suportar POST sem abri-lo ao público. Autenticação identifica o principal; autorização aplica a política; suporte do método informa o que o recurso sabe processar.

O desenho corresponde à Minimum Initial Specification de Heng Lu: o nível comum fixa apenas o significado necessário à interoperabilidade. Regras comerciais e direitos ficam com quem executa o recurso. O registro da IANA é um vocabulário comum, não uma autoridade central de acesso.

Safe separa a intenção do cliente da escolha do servidor

Uma operação segura é essencialmente de leitura em sua semântica definida. O cliente não pede mudança de estado. A RFC observa que o servidor ainda pode escrever logs, cobrar uma conta de publicidade ou produzir outros efeitos. O ponto é que esses efeitos não foram solicitados pelo cliente, que não pode responder por eles.

Essa fronteira permite indexação, verificação de links e prefetch. Também obriga o dono do recurso a impedir ações perigosas sob métodos seguros. Um GET a page?do=delete não pode apagar dados porque a palavra delete apareceu no parâmetro. Um robô que percorre links não expressou vontade de destruir.

O monitoramento precisa manter duas colunas: mudança solicitada e efeito acrescentado. Logs, cobrança, consumo de quota, rastreamento e notificação externa pertencem à segunda. Safe também não significa autorizado: a leitura de um prontuário continua exigindo permissão.

Quando um serviço usa o rótulo para minimizar um efeito de negócio, a pergunta correta é quem escolheu esse efeito, como ele é observado e quem pode revertê-lo. O método não absolve a implementação.

Idempotent não exige a mesma resposta

Uma operação é idempotente quando várias requisições idênticas têm o mesmo efeito pretendido de uma só. PUT, DELETE e os métodos seguros se enquadram nessa propriedade. O servidor pode registrar cada tentativa, criar várias revisões ou responder de forma diferente.

Um DELETE repetido pode encontrar o recurso ausente depois que o primeiro o removeu. Um PUT repetido pode chegar ao mesmo estado com outro ETag. O que converge é o efeito solicitado, não toda a história ao redor.

A aplicação pode romper a promessa. Um PUT que soma um saldo multiplica o resultado. Um DELETE que envia uma nova ordem externa em cada tentativa converge localmente e duplica a consequência fora do recurso.

Por isso são necessárias chaves de operação, estados de commit, deduplicação por sistema e compensação. A propriedade HTTP é evidência inicial, não transação distribuída.

Repetir é decidir sob incerteza

Se a conexão fecha antes da resposta, o cliente pode não saber se o servidor recebeu, aplicou ou apenas respondeu. Repetir um método idempotente é razoável porque a nova tentativa deve alcançar o mesmo efeito pretendido mesmo que a anterior tenha sido efetivada.

A RFC não autoriza loops. Um cliente não deve repetir automaticamente um método não idempotente sem saber que aquela operação concreta converge ou que a primeira não foi aplicada. Um proxy não pode fazê-lo. Uma repetição automática que falha não deve iniciar outra cadeia automática.

O recibo de recuperação inclui ponto da falha, alvo, hash do conteúdo, precondição, chave de idempotência, estado consultável, número de tentativa e backoff. Um POST com identificador estável pode ser recuperável. Um PUT com efeitos externos sem deduplicação pode não ser.

Running-Code Primacy oferece o teste: duplicatas convergem na prática? O commit pode ser consultado? Efeitos externos têm limite? O funcionamento verificável vale mais que a simples citação do rótulo.

If-Match protege uma versão, não concede identidade

If-Match exige que o ETag atual ainda corresponda ao conhecido pelo cliente. Se não corresponder, o servidor não aplica a mudança e normalmente responde 412. O mecanismo evita que uma cópia antiga apague uma edição mais recente.

Conhecer o ETag não dá direito de escrita. Ter direito de escrita não atualiza um ETag vencido. A autorização responde se o principal pode agir; a precondição responde se o estado ainda é aquele assumido. Cada recusa precisa de seu próprio motivo.

Depois de uma resposta perdida, a versão também pode ajudar a reconhecer uma mudança já aplicada. Mas recursos com escritores não coordenados exigem cautela: duas mudanças semelhantes não são necessariamente o mesmo ato.

QUERY torna pública uma qualidade antes invisível

A RFC 10008, publicada em junho de 2026 por Julian Reschke, James Snell e Mike Bishop, define QUERY. Ela não foi escrita por Fielding. QUERY carrega conteúdo como POST, mas declara uma consulta segura e idempotente. A IANA registra ambas as propriedades como yes.

Consultas complexas em URI podem ser longas e aparecer em logs ou históricos. Muitas aplicações usam POST para ler. Para um componente genérico, esse POST parece potencialmente modificador porque a segurança só existe no conhecimento privado da aplicação. QUERY torna a intenção visível, enquanto o recurso continua definindo o conteúdo e decidindo o suporte.

Registro não é implantação. Um gateway pode não encaminhar; o servidor pode responder 501; o recurso pode responder 405; o principal pode não ter acesso. A linha da IANA é um ledger de semântica, não uma ACL.

A contribuição de Fielding termina na fronteira da atribuição

O Datatracker do IETF consultado em 31 de agosto de 2026 descreve Roy T. Fielding como Senior Principal Scientist na Adobe, cofundador da The Apache Software Foundation, autor do REST e colaborador em HTTP, URI e URI Templates. Lista 18 RFCs e uma função de revisor no HTTP Directorate. A UC Irvine registra seus diplomas e suas contribuições ao Web e ao Apache.

Sua tese trata a interface uniforme como restrição que aumenta visibilidade, reutilização, escala e evolução independente, em troca de parte da eficiência específica de uma aplicação. O vocabulário de métodos materializa essa escolha: revela intenção suficiente sem centralizar armazenamento, política e execução.

A RFC 9110 tem três editores: Fielding, Mark Nottingham e Julian Reschke. HTTP é trabalho coletivo e acumulado. A RFC 10008 pertence aos autores nomeados. A assinatura torna a contribuição auditável, não o protocolo propriedade de uma pessoa.

O recibo de operação começa onde o token termina

Registrar método, URI e origem; principal autenticado e escopo; suporte do recurso; decisão e versão da política; ETag; hash do conteúdo e efeito pretendido. Após falha, acrescentar o último ponto confirmado, a possibilidade de aplicação da primeira tentativa, a chave de operação, o ator, motivo, contagem e espera da repetição.

Encerrar com resposta, estado relido, efeitos a jusante, compensações e consequências irreversíveis. Assim, cada prova responde à sua pergunta. O método informa o que o cliente pretende. O recurso informa se entende. A política informa se aquele principal pode agir. A precondição informa se o estado continua válido. A recuperação informa se cabe repetir.

O método nomeia uma intenção. Ele não concede permissão.

Fontes