Método HTTP para ação CRUD: verbo REST e código de status
Digite create e receba o método convencional com 201 Created, uma dica de rota e uma nota sobre a convenção; update devolve PUT para substituição completa e cita o PATCH para mudanças parciais. A mesma ação sempre dá a mesma resposta. Grátis no seu navegador.
- Grátis
- Funciona no seu navegador
- Sem cadastro
- Seus dados não saem do seu aparelho
Executar grátis
Exemplo resolvido
- Ação
- create
- Status
- 201
- Texto de status
- Created
- Dica de caminho
- POST /resources
É um mapeamento determinístico, não um palpite: a mesma ação sempre produz a mesma resposta, sem nenhum modelo envolvido. Ações não reconhecidas são rejeitadas com um erro claro que lista os valores aceitos, de modo que um erro de digitação na automação falha ruidosamente em vez de gerar silenciosamente uma rota errada.
Por que PUT para update, e onde o PATCH se encaixa
A célula mais debatida da tabela é a de update. O PATCH existe para o outro caso comum, em que o cliente envia apenas os campos que mudaram e o servidor os mescla; a nota retornada diz isso explicitamente, de modo que quem revisa vê a alternativa em vez de tratar o mapeamento como dogma. Na prática, muitas APIs em produção usam PATCH para atualizações parciais e reservam PUT para substituição completa, e algumas ignoram o PUT por completo.
O importante para um design é escolher uma convenção e aplicá-la uniformemente a todos os recursos, o que é exatamente o tipo de decisão que uma consulta determinística ajuda a impor quando integrada a ferramentas de scaffolding e a checklists de revisão de código.
Os códigos de status são metade da resposta
Um create que responde 200 OK em vez de 201 Created não está quebrado, mas desperdiça um sinal que a especificação oferece de graça, e clientes automatizados que decidem com base no status vão interpretá-lo errado. Um delete que responde 200 com corpo vazio obriga o cliente a analisar nada onde 204 No Content teria dito tudo na linha de status.
O mapeamento retornado aqui associa cada ação ao status que uma chamada bem-sucedida deve produzir — 201 para create, 200 para read, update e list, 204 para delete — junto com a frase de razão padrão, de modo que a documentação gerada e as seções de respostas do OpenAPI saem corretas por construção.
Os erros ficam deliberadamente fora do escopo: a capacidade responde apenas à convenção do caminho feliz e rejeita nomes de ação não reconhecidos com uma mensagem clara que lista os cinco valores aceitos, em vez de adivinhar uma correspondência aproximada.
Perguntas frequentes
Quanto custa?
O mesmo mapeamento também roda de graça no seu navegador, nesta página.
Quais ações são aceitas?
create, read, update, delete e list. A comparação não diferencia maiúsculas de minúsculas e espaços ao redor são ignorados; qualquer outro valor é rejeitado com um erro que lista os valores aceitos.
Por que PUT e não PATCH para update?
PUT é a substituição completa idempotente convencional, que é o que o mapeamento retorna. A nota na resposta aponta o PATCH como a escolha padrão para atualizações parciais, para que você decida de forma consciente.
A resposta é alguma vez aleatória ou gerada por modelo?
Não. O mapeamento é uma tabela determinística fixa; a mesma ação sempre retorna o mesmo método, status e nota.
Uma ação de criar deve responder 200 ou 201?
201 Created, geralmente com um cabeçalho Location apontando para o novo recurso. Um 200 OK não está errado, mas desperdiça um sinal que a especificação já oferece, e clientes que decidem pelo status vão interpretá-lo mal.
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/dev/http-method-from-action-suggest \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"action":"create"}'const res = await fetch("https://api.kit.forhosting.com/dev/http-method-from-action-suggest", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"action": "create"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/http-method-from-action-suggest",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"action": "create"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/http-method-from-action-suggest", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"action":"create"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"action":"create"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/http-method-from-action-suggest", 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
{
"action": "create"
}Exemplo de resposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.http_method_from_action_suggest",
"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
O endpoint de método HTTP para ação CRUD responde à pergunta que todo projetista de API faz dezenas de vezes por dia: dada uma ação como create, read, update, delete ou list, qual método HTTP o endpoint deve usar e qual código de status uma chamada bem-sucedida deve retornar? Você envia um único nome de ação e recebe de volta o verbo REST convencional, o status de sucesso típico com sua frase de razão, uma dica de caminho mostrando como a rota costuma ser escrita e uma nota curta explicando a convenção. Use ao criar o esqueleto de rotas, revisar um design de API, gerar estruturas OpenAPI ou ensinar convenções REST a uma equipe que vive confundindo PUT e PATCH.
O mapeamento convencional, em uma tabela
O REST mapeia as quatro operações de persistência para os verbos HTTP, além da leitura de coleção de que toda API real também precisa. Create corresponde a POST na coleção e, por convenção, responde 201 Created, muitas vezes com um cabeçalho Location apontando para o novo recurso. Read corresponde a GET em um recurso individual e responde 200 OK; é seguro e idempotente, e é por isso que caches e novas tentativas podem ser agressivos com ele. Update corresponde a PUT quando o cliente substitui o recurso por completo, respondendo 200 OK com a representação atualizada; o mesmo endpoint é idempotente, portanto uma requisição repetida não causa dano extra. Delete corresponde a DELETE e normalmente responde 204 No Content, já que não resta nada para descrever. List corresponde a GET na coleção, respondendo 200 OK, e é onde moram os parâmetros de consulta de paginação, filtragem e ordenação. Este endpoint retorna exatamente essa linha da tabela, com o raciocínio anexado, de modo que a resposta pode ser colada em um documento de design ou verificada em um teste sem reler um guia de estilo.
Por que PUT para update, e onde o PATCH se encaixa
Esta capacidade segue a leitura mais estrita da especificação HTTP: PUT substitui o recurso inteiro pela representação que o cliente envia, o que o torna idempotente — enviar o mesmo PUT duas vezes deixa o servidor exatamente no mesmo estado. Essa propriedade é o que faz do PUT o padrão convencional para um endpoint de atualização e a resposta que esta API dá para a ação update.
Os códigos de status são metade da resposta
Escolher o verbo é apenas metade do design de um endpoint; o código de status de sucesso é a outra metade, e errá-lo confunde os clientes.
Casos de integração
Criar esqueleto de rotas REST
Gere esboços de rotas para um novo recurso com o verbo e o status convencionais já preenchidos para cada ação CRUD.
Revisar um design de API
Compare uma lista de endpoints proposta com o mapeamento convencional e sinalize as rotas que divergem antes de irem ao ar.
Ensinar convenções REST
Dê à equipe uma referência determinística única para a questão de verbo e status, em vez de rediscuti-la em cada revisão.
Perguntas técnicas
Ele cobre códigos de status de erro?
Não. Ele responde apenas ao caminho de sucesso convencional: o método HTTP, o código de status de sucesso típico e uma breve explicação da convenção.
O que acontece com uma ação não reconhecida?
A requisição falha com um erro invalid_input cuja mensagem informa o valor recebido e lista as cinco ações aceitas.