Resumo

  • 202 Accepted informa que a solicitação foi aceita para processamento enquanto esse processamento permanece incompleto.
  • A operação ainda pode ser rejeitada, cancelada, expirar, perder autorização ou terminar sem o efeito esperado.
  • Decisões que dependem da conclusão precisam de um comprovante de operação assíncrona que ligue a solicitação original ao monitor oficial e ao resultado terminal.

Imagine um controlador de mudanças solicitando a rotação de uma política de acesso. O serviço devolve 202 Accepted com um link para a operação. O controlador marca a mudança como concluída, revoga a credencial anterior e apaga o material de entrada. Minutos depois, a operação chega ao processo executor, que verifica novamente a política e a rejeita. A solicitação foi aceita. A mudança nunca foi executada.

O erro não está no código de status. Está em promover uma etapa de uma operação distribuída a prova de todas as etapas posteriores.

A RFC 9110 define 202 Accepted de forma restrita. O servidor aceitou a solicitação para processamento, mas o processamento ainda não terminou. A solicitação pode ou não ser atendida, pois ainda pode ser considerada inadmissível quando chegar o momento de processá-la. A resposta é deliberadamente não conclusiva.

Esse limite importa porque a troca HTTP já terminou. A RFC 9110 observa que o HTTP não oferece um meio de reenviar mais tarde, pela troca já concluída, o código de status da operação assíncrona. Um cliente que trata o primeiro 202 como sucesso terminal inventa uma continuação que o protocolo não entregou.

A representação da resposta deveria descrever o estado atual e apontar ou incorporar um monitor de status. A orientação é útil, mas uma URL isolada não é um comprovante de conclusão. O monitor precisa servir como referência oficial para a mesma operação, ser acessível no contexto de segurança esperado, permanecer disponível pelo período necessário e indicar com clareza os estados terminais. Uma página genérica de fila, um endereço mutável de “última tarefa” ou um link que depois retorna 404 não sustenta uma decisão irreversível.

A RFC 7240 oferece um sinal relacionado, porém distinto. O cliente pode enviar Prefer: respond-async para expressar preferência por tratamento assíncrono, e o servidor pode atender a essa preferência com 202. A preferência seleciona o modo de interação; não comprova que o trabalho adiado foi executado. A especificação deixa o mecanismo de obtenção do resultado final a cargo da implementação.

Preference-Applied tem alcance igualmente limitado. Segundo a RFC 7240, o campo pode indicar quais preferências da solicitação o servidor respeitou. Portanto, confirma que o tratamento assíncrono foi escolhido. Não confirma o início de um worker, uma gravação, uma notificação, uma implantação nem qualquer outro efeito posterior.

Um registro operacional deve preservar ao menos três fatos distintos. Primeiro, a aceitação: quais bytes, identidade solicitante, alvo, chave de idempotência e resposta foram observados, e em qual ponto. Segundo, a execução: qual identificador entrou em qual fila, qual processo assumiu a operação, quais verificações de autorização e dependências estavam atualizadas e se houve cancelamento ou expiração. Terceiro, o resultado: quais efeitos foram confirmados, qual estado terminal foi devolvido e se esse estado ainda serve como referência oficial.

Essas ligações se perdem facilmente. Um gateway pode emitir o 202 enquanto outro serviço controla a fila. A URL da operação pode identificar uma tarefa vinculada a um cliente e mudar de significado sob outra credencial. Uma nova tentativa pode recuperar a mesma tarefa ou criar outra quando não há idempotência. O processo executor pode começar depois que o solicitante perdeu a autoridade. Um sinal de “sucesso” pode ser gravado antes que o efeito a jusante seja observável.

Nada disso torna o 202 defeituoso. A aceitação assíncrona é valiosa justamente porque a conexão não precisa permanecer aberta durante um processo longo. A disciplina correta é preservar a resposta como evidência de aceitação e obter evidência posterior para cada alegação posterior.

O comprovante necessário é um recibo de operação assíncrona. Ele vincula método, alvo e resumo do corpo à identidade autenticada, ao estado da autorização naquele momento, à chave de idempotência, ao ponto de observação, à resposta 202, ao identificador da operação e ao URI do monitor que serve de referência. Depois registra a entrada na fila, a retirada da tarefa pelo processo executor, novas verificações de autorização e dos sistemas dos quais a operação depende, o cancelamento, os identificadores dos efeitos, o resultado terminal, o horário de observação e a decisão que usou esse resultado.

Fontes

RFC 9110 — HTTP Semantics, 202 Accepted; RFC 7240 — Prefer Header for HTTP.