Código de status HTTP · Sucesso (2xx)
202 Accepted
O 202 Accepted significa que o servidor aceitou o pedido para processar, mas ainda não terminou, e o trabalho ainda pode falhar depois. É a resposta certa quando você coloca uma tarefa na fila, como converter um vídeo ou gerar uma exportação grande, e responde antes de ela acabar.
| Classe | 2xx, Sucesso |
|---|---|
| Definido em | RFC 9110 §15.3.3 |
| Pode ir para o cache por padrão | Só com Cache-Control ou Expires explícitos |
| Pode repetir o pedido | Não reenvie; consulte a URL de status |
| Cabeçalhos relevantes |
|
O que significa o 202
A RFC 9110, seção 15.3.3, descreve o 202 como propositalmente evasivo. O HTTP não tem como enviar um segundo status depois para o mesmo pedido, então a resposta deve descrever o estado atual e apontar para um monitor de status onde o cliente acompanha o andamento.
Um formato comum: POST /exportacoes devolve 202 com Location: /exportacoes/tarefas/7f3a. O GET nessa tarefa devolve 200 com {"status": "processando"} enquanto roda, e depois um link para o arquivo pronto, ou um 303 See Other até ele. Muitas APIs também mandam Retry-After para sugerir o intervalo de consulta; é convenção, porque a RFC 9110 só define o Retry-After para 503, 429 e redirecionamentos.
Quando usar
- Trabalho que dura mais que um timeout razoável: processamento de mídia, importações em massa, geração de relatórios, envio de e-mails em lote.
- Receptores de webhook que guardam o evento e processam depois; a maioria dos remetentes de webhook só precisa de um 2xx rápido.
Causas comuns
Se você administra o servidor
- O cliente trata o 202 como "pronto" e mostra sucesso, depois a tarefa em segundo plano falha e ninguém fica sabendo.
- Não existe recurso de status, então o cliente reenvia a tarefa para descobrir o que houve e cria duplicatas.
Como resolver
Se você administra o servidor
- Devolva sempre uma URL da tarefa (cabeçalho Location ou link no corpo) cujo status passe por na fila, rodando, concluída ou falhou.
- Em tarefas longas, ofereça uma URL de retorno ou webhook para o cliente nem precisar consultar.
Como enviar um 202
app.post('/exports', (req, res) => {
res.set('Location', '/exports/jobs/7f3a');
res.status(202).json({ status: 'queued', statusUrl: '/exports/jobs/7f3a' });
});// app/exports/route.ts
export async function POST() {
return Response.json(
{ status: 'queued', statusUrl: '/exports/jobs/7f3a' },
{ status: 202, headers: { 'Location': '/exports/jobs/7f3a' } }
);
}mux.HandleFunc("POST /exports", func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Location", "/exports/jobs/7f3a")
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusAccepted) // 202
w.Write([]byte(`{"status":"queued","statusUrl":"/exports/jobs/7f3a"}`))
})from fastapi import FastAPI
from fastapi.responses import JSONResponse
app = FastAPI()
@app.post("/exports")
def start_export():
return JSONResponse(status_code=202, content={"status": "queued", "statusUrl": "/exports/jobs/7f3a"}, headers={"Location": "/exports/jobs/7f3a"})Costuma ser confundido com
- 202 vs 201
- O 201 Created afirma que o recurso já existe; o 202 só garante que o trabalho foi aceito e pode concluir, ou falhar, depois.
- 202 vs 204
- O 204 indica que a ação terminou e não há nada a devolver; o 202 indica que ainda não terminou.
Perguntas frequentes
- O 202 Accepted significa que o pedido deu certo?
- Só que foi aceito. A RFC 9110 diz que o pedido pode ou não ser executado no fim, então o resultado real precisa ser conferido depois, por um recurso de status ou por um retorno do servidor.
- Como o cliente descobre o resultado de um 202?
- Por uma URL que o servidor devolve, geralmente no cabeçalho Location ou no corpo. O cliente consulta até a tarefa informar sucesso ou falha, ou o servidor chama um webhook ao terminar.
- Um endpoint de webhook deve responder 200 ou 202?
- Os dois servem para a maioria dos remetentes, que só procuram um 2xx. O 202 é mais preciso quando você guarda o evento e processa de forma assíncrona.
Revisado em por Arielton Oberek.