Prompt y alcance
Un entrevistador podría preguntar: “¿Qué significan las respuestas provisionales HTTP 1xx y 102 Processing? Si una solicitud larga necesita retroalimentación de progreso, ¿cómo la diseñaría?”
La señal radica en si usted puede separar una señal de protocolo de que la solicitud no ha terminado, una respuesta final y un recurso de operación asíncrona. RFC 9110 permite cero o más respuestas provisionales 1xx antes de la respuesta final no-1xx; no convierte a 102 en un protocolo genérico de progreso porcentual. 102 se originó como un estado de WebDAV en RFC 2518 y fue eliminado de WebDAV por RFC 4918. Comience verificando versiones de protocolo, clientes e intermediarios antes de proponerlo.
Qué está evaluando el entrevistador
- Si sabe que las respuestas 1xx son provisionales y no completan una solicitud.
- Si puede distinguir entre 100 Continue, 101 Switching Protocols y 102 Processing.
- Si reconoce la historia de 102 en WebDAV en lugar de prometer soporte universal.
- Si puede elegir 202 junto con un recurso de estado, SSE o WebSocket para un flujo de producto de larga duración.
- Si toma en cuenta proxies, tiempos de espera, reintentos, cancelación, idempotencia y recuperación de resultados.
Preguntas para clarificar
- ¿La solicitud debe permanecer sincrónica o el trabajo puede convertirse en una operación en segundo plano?
- ¿El proxy inverso y la pasarela reenviarán y expondrán las respuestas 1xx?
- ¿El producto necesita una indicación de keep-alive o etapas y porcentajes observables?
- ¿La operación tiene efectos secundarios que un reintento podría repetir?
- ¿Existe un recurso de resultado independiente con expiración y control de acceso?
Una respuesta de 30 segundos
Puede decir:
Una respuesta 1xx es provisional; el cliente aún necesita una respuesta final que no sea 1xx. 102 Processing provino de un escenario de operaciones largas de WebDAV, por lo que no es un modelo general de progreso y no se puede asumir que atraviese todos los intermediarios. Si el trabajo puede ser asíncrono, devolvería 202 con un recurso de estado autorizado que exponga estados estables, errores, cancelación y un enlace al resultado. Si la conexión debe permanecer abierta, consideraría SSE u otro protocolo de eventos explícito según el soporte del cliente, y luego probaría la ruta real del proxy.
Razonamiento paso a paso
Definir el ciclo de vida de la respuesta
Separe las etapas provisionales y finales:
HTTP/1.1 102 Processing
HTTP/1.1 200 OK
Content-Type: application/json
{"result":"done"}102 no finaliza la solicitud ni promete su finalización. La restricción importante de RFC 9110 es que aún le sigue una respuesta final que no es 1xx; perder una respuesta provisional no prueba por sí sola una falla de negocio.
Establecer el límite para 102
RFC 2518 describió 102 como una sugerencia de WebDAV durante una operación prolongada, ayudando a que el cliente evite tratar una conexión activa como muerta. No es un recurso de flujo de trabajo con percentComplete, valores de etapa y semántica de errores estandarizados. RFC 4918 eliminó esa definición de WebDAV, por lo que una nueva API debe documentar sus implementaciones de destino y compatibilidad en lugar de depender únicamente del número.
Elegir un protocolo para la necesidad del producto
Cuando el sondeo sea aceptable, separe la acción de su estado: devuelva 202 y un Location para el envío, luego exponga estados estables como Pending, Running, Succeeded, Failed y Canceled. Agregue SSE cuando una interfaz de usuario en vivo requiera actualizaciones de etapa; evalúe WebSocket solo cuando el control bidireccional esté justificado. Cada opción necesita un plan para reconexiones, backoff, cancelación y autorización.
Manejar envíos duplicados y la finalización eventual
Acepte una clave de idempotencia para la creación y persista una huella digital de la solicitud junto con el ID de la operación. Un reintento con la misma clave devuelve la misma operación en lugar de encolar otro efecto secundario. Haga que las lecturas de estado sean repetibles, proteja las URL de resultados con comprobaciones de inquilino y expiración, y exponga errores estructurados con un límite de reintentos. Una desconexión, tiempo de espera agotado o respuesta 102 no es una conclusión de negocio.
Respuesta modelo de alta calidad
Primero distinguiría una indicación de keep-alive de un progreso observable. Si una solicitud sincrónica puede exceder el tiempo de espera de una pasarela, no usaría 102 como una API de progreso genérica: 1xx es provisional, 102 tiene antecedentes en WebDAV y el soporte de los intermediarios es irregular. Mi opción predeterminada es validar el envío, devolver 202 con un ID de operación y una URL de estado, y exponer información de etapas delimitada, hora de actualización, errores estructurados, cancelación y una URL de resultado. El envío incluye una clave de idempotencia para que los reintentos no creen trabajo duplicado. Para una interfaz de usuario en vivo puedo agregar SSE, con recuperación a través del último ID de evento o el recurso de estado. Los riesgos de seguridad o cumplimiento siguen utilizando la ruta formal de escalamiento y auditoría. Esto mantiene separados las señales de protocolo, el estado de la operación y los recursos de resultados.
Errores comunes
- Llamar a 102 una respuesta de progreso porcentual sin un contrato de campos o de cliente.
- Tratar cualquier 1xx como éxito o como permiso para cerrar la conexión.
- Ignorar la eliminación de 102 de WebDAV en RFC 4918 y afirmar un soporte universal para WebDAV.
- Hablar solo del servidor de origen omitiendo pruebas de CDN, proxy, pasarela y navegador.
- Devolver 202 sin un recurso de estado, estrategia de idempotencia, estado de falla o autorización de resultados.
- Tratar desconexiones, tiempos de espera agotados o reintentos como prueba de falla y duplicar efectos secundarios.
Preguntas de seguimiento y respuestas
1. ¿Cuál es la diferencia clave entre 102 y 202?
102 es una respuesta provisional para la misma solicitud; la respuesta final aún está pendiente. 202 es la respuesta final que indica que la solicitud fue aceptada para su procesamiento, aunque el resultado podría no estar listo. Para un trabajo observable y recuperable de forma independiente, 202 junto con un recurso de estado suele ser más claro.
2. ¿Qué pasa si un proxy no reenvía respuestas 1xx?
Trate a 1xx como una optimización opcional, nunca como la única señal de corrección. Proporcione un estado recuperable a través de un endpoint de estado, SSE o una ruta de cliente controlada, y pruebe la cadena real de intermediarios.
3. ¿Cuándo seguiría utilizando 102?
Solo cuando la pila de extremo a extremo lo admita explícitamente, el requisito sea una indicación provisional para la misma solicitud larga y el equipo acepte el límite de compatibilidad. Registre evidencia de clientes, proxies y tiempos de espera, y mantenga un mecanismo de reserva correcto que funcione sin 102.