Verifique se um método HTTP é seguro ou idempotente
Saiba se um método pode ser repetido sem surpresas: put, digitado com espaços, é lido como PUT, não seguro mas idempotente, então enviá-lo duas vezes tem o mesmo efeito pretendido que enviá-lo uma vez. Grátis no seu navegador.
- Grátis
- Funciona no seu navegador
- Sem cadastro
- Seus dados não saem do seu aparelho
Executar grátis
Seguro e idempotente são promessas diferentes
Um método seguro serve para obter informações ou perguntar quais opções um servidor oferece, não para mudar nada nele. HEAD, OPTIONS e TRACE fazem parte desse grupo, e todo método seguro também é idempotente. Idempotente é uma promessa mais ampla: enviar a mesma mensagem várias vezes tem o mesmo efeito pretendido que enviá-la uma só vez. PUT e DELETE cumprem essa promessa sem serem seguros, porque gravar de novo o mesmo conteúdo ou apagar de novo o mesmo item não acrescenta nenhum efeito novo.
Quando verificar antes de repetir
A pergunta importa principalmente quando a conexão cai e não dá para saber se o servidor recebeu a mensagem. Antes de ativar repetições automáticas para um método, verifique aqui: você recebe o método em maiúsculas, se ele é seguro, se é idempotente e um rótulo curto que resume tudo. Maiúsculas e espaços sobrando não contam, então put vira PUT. Um erro comum é achar que idempotente quer dizer inofensivo: DELETE muda dados, só não os muda duas vezes. Nomes desconhecidos ou inventados são recusados em vez de adivinhados.
Interprete as tentativas novamente de forma correta
A idempotência é especialmente útil quando você precisa decidir se um cliente automatizado pode repetir uma solicitação após uma falha de conexão. O cliente talvez não saiba se o servidor recebeu a primeira tentativa; repetir um método idempotente preserva o efeito pretendido da solicitação. Isso não garante códigos de status nem corpos de resposta idênticos.
Por exemplo, o primeiro DELETE pode remover um recurso e retornar sucesso, enquanto outro DELETE idêntico pode informar que o recurso já não existe; o estado final pretendido continua igual. PUT apresenta a mesma propriedade quando as solicitações repetidas mantêm o destino e a representação.
Casos de uso
Revise o middleware de repetição
Verifique um método configurado antes de ativar novas tentativas automáticas após falhas de transporte ambíguas.
Perguntas frequentes
Por que DELETE é idempotente se a segunda tentativa pode retornar outro status?
Idempotência diz respeito ao efeito pretendido no servidor, não a respostas idênticas. Solicitações repetidas de exclusão buscam o mesmo estado final do recurso.
Nomes de métodos em letras minúsculas são aceitos?
Sim. O verificador remove os espaços externos e normaliza o nome informado para letras maiúsculas antes da classificação.
O que acontece com métodos WebDAV ou personalizados?
Eles são rejeitados como desconhecidos. Suas propriedades devem vir da especificação ou do contrato da aplicação que os define.
Qual é a diferença entre um método seguro e um idempotente?
Um método seguro só consulta informações e não pede nenhuma mudança no servidor. Um idempotente pode mudar coisas, mas enviá-lo duas vezes tem o mesmo efeito pretendido que enviá-lo uma vez. PUT e DELETE são idempotentes sem serem seguros.
Quais métodos são reconhecidos?
Os nove métodos padrão do protocolo web e da especificação do PATCH, como PUT, PATCH, DELETE, HEAD, OPTIONS e TRACE. Maiúsculas e espaços ao redor do nome são ignorados, então put é lido como PUT.
Ferramentas relacionadas
Para desenvolvedores — acesso via API
Tudo nesta página está disponível via API. Esta seção é para equipes que querem integrar a ferramenta aos próprios sistemas; quem não precisa disso pode simplesmente usar a ferramenta acima.
Endpoint
Autenticação por token Bearer. Um único POST coloca a tarefa na fila; o resultado chega por webhook ou link assinado.
Chame do seu código
curl -X POST https://api.kit.forhosting.com/dev2/http-method-idempotent-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"method":"PUT"}'const res = await fetch("https://api.kit.forhosting.com/dev2/http-method-idempotent-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"method": "PUT"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/http-method-idempotent-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"method": "PUT"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/http-method-idempotent-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"method":"PUT"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"method":"PUT"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/http-method-idempotent-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemplo de requisição
{
"method": "PUT"
}Exemplo de resposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.http_method_idempotent_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}A API é assíncrona: cada chamada devolve um task_id na hora. Se preferir polling, consulte o status a até 1 requisição por segundo.
Preço
Preço publicado, sem tokens nem créditos escondidos. Tarefa que falha não é cobrada.
Erros
| HTTP | Código | O que significa |
|---|---|---|
401 | unauthorized | Token ausente ou inválido. Confira o header Authorization. |
402 | insufficient_balance | Saldo insuficiente para esta tarefa. Faça uma recarga e tente de novo. |
404 | unknown_type | Esse tipo de tarefa não existe. Confira o campo type no catálogo. |
429 | rate_limited | Muitas requisições em pouco tempo. Espere um instante e tente de novo. |
Notas técnicas
Classifique um método HTTP padrão pelas propriedades de segurança e idempotência definidas na semântica HTTP. Informe um método como GET, POST, PUT, PATCH ou DELETE e receba o nome normalizado, resultados booleanos separados e uma classificação conjunta objetiva. O verificador reconhece os nove métodos definidos pelas principais especificações de semântica HTTP e PATCH, desconsidera espaços externos e diferenças entre maiúsculas e minúsculas, e rejeita nomes desconhecidos em vez de presumir propriedades de métodos de extensão.
Diferencie segurança de idempotência
Segurança e idempotência representam garantias distintas. Um método seguro se destina a recuperar informações ou comunicar opções, e não a solicitar uma alteração de estado no servidor de origem. A idempotência é mais abrangente: várias solicitações idênticas produzem o mesmo efeito pretendido no servidor que uma única solicitação. PUT e DELETE são idempotentes mesmo sem serem seguros, pois substituir uma representação repetidamente pela mesma representação, ou solicitar várias vezes a exclusão do mesmo recurso, não acrescenta um novo efeito pretendido a cada execução. GET, HEAD, OPTIONS e TRACE são seguros. A semântica HTTP também determina que todo método seguro é idempotente, por isso esses métodos recebem a classificação conjunta `safe_and_idempotent`. A resposta apresenta `safe` e `idempotent` separadamente para que o código de políticas não precise deduzir uma propriedade a partir de um rótulo. Ela também retorna o campo `classification`, adequado para exibição, registros e decisões simples. Essas propriedades descrevem a semântica padronizada da solicitação; elas não afirmam que uma implementação específica esteja livre de falhas ou de efeitos colaterais incidentais.
Interprete as tentativas novamente de forma correta
POST e PATCH são classificados como não seguros e não idempotentes em suas definições gerais. Uma API específica pode criar uma operação POST ou PATCH que aceite repetição, talvez por meio de uma chave de idempotência ou solicitação condicional, mas esse contrato da aplicação não altera a propriedade padronizada do método. Use o resultado como referência do protocolo e depois aplique quaisquer garantias mais fortes documentadas expressamente pela API utilizada.
Valide o nome antes de aplicar uma política
Presumir as propriedades de um método de extensão pelo nome poderia autorizar uma repetição insegura ou bloquear uma operação válida. Caso o seu sistema use um método de extensão, consulte a especificação que o registra ou define e trate-o por meio de uma política explícita. O algoritmo não faz solicitações de rede nem observa servidores, rotas, caches, proxies ou corpos reais. O verificador aceita os nomes padrão CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT e TRACE. A entrada tem os espaços externos removidos e é convertida para maiúsculas; portanto, valores como ` get ` e `patch` são normalizados sem alteração de significado. Qualquer outro valor gera um erro `invalid_input`. Essa rigidez é importante porque os tokens de método HTTP são extensíveis: WebDAV e outros protocolos definem métodos adicionais, e APIs privadas podem introduzir tokens próprios. Ele é determinístico e apropriado para linters, verificações de documentação de API, configuração de middleware de repetição e ferramentas educacionais no navegador. O executor do navegador e o manipulador da API compartilham a mesma lógica; uma solicitação de API usa o preço-base publicado de US$ 0,002.
Casos de integração
Valide a documentação da API
Compare os métodos escolhidos para endpoints com documentos que declaram uma operação segura ou idempotente.
Ensine semântica HTTP
Apresente separadamente as propriedades de segurança e idempotência dos métodos comuns em uma consulta determinística.
Perguntas técnicas
Todo método seguro também é idempotente?
Sim. A semântica HTTP define métodos seguros como idempotentes; portanto, GET, HEAD, OPTIONS e TRACE têm as duas propriedades.
PATCH é idempotente?
PATCH não é idempotente por padrão. Uma API pode definir uma operação PATCH que aceite repetição, mas essa é uma garantia específica da aplicação.