Resumen

  • 202 Accepted indica que la solicitud fue aceptada para su procesamiento mientras este sigue incompleto.
  • La operación todavía puede ser rechazada, cancelada, caducar, perder autorización o terminar sin el efecto previsto.
  • Una decisión que dependa de la finalización necesita un recibo de operación asíncrona que una la solicitud original con el monitor que constituye la referencia oficial y con el resultado terminal.

Imaginemos un controlador de cambios que solicita rotar una política de acceso. El servicio responde 202 Accepted e incluye un enlace a la operación. El controlador da el cambio por terminado, revoca la credencial anterior y elimina el material de entrada. Minutos después, la tarea llega a un trabajador, que vuelve a comprobar la política y la rechaza. La solicitud fue aceptada; el cambio nunca se ejecutó.

El problema no está en el código de estado. Está en convertir una etapa de una operación distribuida en prueba de todas las etapas posteriores.

RFC 9110 define 202 Accepted con precisión limitada: el servidor aceptó la solicitud para procesarla, pero el procesamiento no ha finalizado. La solicitud podría ser atendida o no, porque todavía puede resultar inadmisible cuando llegue el momento de procesarla. La respuesta es deliberadamente no concluyente.

Ese límite importa porque el intercambio HTTP ya terminó. RFC 9110 señala que HTTP no dispone de un mecanismo para volver a enviar más tarde, dentro de ese intercambio concluido, el código de estado de la operación asíncrona. Cuando un cliente eleva el primer 202 a éxito terminal, inventa una continuación que el protocolo nunca entregó.

La representación de la respuesta debería describir el estado actual y señalar o incorporar un monitor de estado. Es una orientación valiosa, pero una URL no constituye por sí sola un recibo de finalización. El monitor debe ser la referencia oficial para esa misma operación, accesible en el contexto de seguridad previsto, conservarse durante el tiempo necesario y distinguir con claridad los estados terminales. Una página genérica de cola, un endpoint mutable de “último trabajo” o un enlace que después responde 404 no sostienen una decisión irreversible.

RFC 7240 aporta una señal relacionada, pero distinta. El cliente puede enviar Prefer: respond-async para expresar una preferencia por el tratamiento asíncrono, y el servidor puede atenderla con una respuesta 202. Esa preferencia selecciona una forma de interacción; no demuestra que el trabajo diferido se haya realizado. La especificación deja el mecanismo para conocer el resultado final a cada implementación.

Preference-Applied tiene un alcance igualmente estrecho. Según RFC 7240, informa qué preferencias de la solicitud fueron respetadas. Puede confirmar que se eligió el modo asíncrono. No confirma el inicio de un trabajador, una escritura, una notificación, un despliegue ni ningún otro efecto posterior.

Un registro operativo debe separar al menos tres hechos. Primero, la aceptación: qué bytes, principal, destino, clave de idempotencia y respuesta se observaron, y desde qué punto. Segundo, la ejecución: qué identificador entró en qué cola, qué trabajador lo reclamó, qué controles de autorización y dependencias estaban vigentes, y si intervinieron cancelación o caducidad. Tercero, el resultado: qué efectos se confirmaron, qué estado terminal se devolvió y si ese estado sigue siendo la referencia oficial.

Es fácil perder esas uniones. La pasarela puede emitir el 202 mientras otro servicio posee la cola. El enlace de operación puede identificar una tarea relativa a un inquilino y cambiar de significado bajo otras credenciales. Un reintento puede recuperar el mismo trabajo o crear otro cuando falta idempotencia. El trabajador puede empezar después de que el principal haya perdido autoridad. Incluso un estado “correcto” puede registrarse antes de que el efecto aguas abajo sea observable.

Nada de ello hace defectuoso al 202. La aceptación asíncrona es útil precisamente porque una conexión no necesita permanecer abierta durante una operación larga. La disciplina consiste en conservar la respuesta como evidencia de aceptación y exigir evidencia posterior para afirmaciones posteriores.

El objeto probatorio útil es un recibo de operación asíncrona. Vincula método, destino y resumen del cuerpo con el principal autenticado, la época de autorización, la clave de idempotencia, el punto de observación, la respuesta 202, el identificador de operación y el URI del monitor que constituye la referencia oficial. Después registra admisión en cola, reclamación por un trabajador, nuevos controles de autorización y dependencias, cancelación, identificadores de efectos, resultado terminal, hora de observación y decisión que consumió ese resultado.

Fuentes

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