Una solicitud aceptada necesita un resultado visible
En trabajos en segundo plano, el portal debe mostrar la aceptación y el desenlace. Una consulta de estado correcta puede informar de un fallo.
Un mensaje de éxito en el portal debe acreditar el estado en el que se apoya el usuario. Quien espera un informe terminado necesita poder recuperarlo. La aceptación de su creación es un paso intermedio. Esta distinción forma parte de la decisión de producto sobre la información mostrada.
MDN describe HTTP 202 como la aceptación de un procesamiento todavía no completado. El trabajo puede fallar después. Microsoft muestra una consulta de estado separada para esos flujos asíncronos. Por tanto, el código HTTP de la primera respuesta no resuelve qué debe mostrar el portal a continuación.
La misma aceptación, dos interfaces
En nuestro portal ficticio se acepta el trabajo de informe J-73. La plantilla existe inicialmente, pero se elimina antes del procesamiento. La siguiente comparación describe dos interfaces posibles, no una prueba de usuarios realizada.
Estado del trabajo | Interfaz A | Interfaz B |
|---|---|---|
| Ya anuncia «Informe listo». | Indica «Aceptado para procesamiento» y muestra la referencia del trabajo. |
| Sigue mostrando el mismo mensaje de éxito. | Muestra la creación en curso. |
| Mantiene el mensaje de éxito. | Informa del error y de una vía para resolverlo. |
Ambas interfaces podrían haber recibido la misma respuesta de aceptación. Aun así, ofrecen información distinta. En A, la aceptación técnica puede ocultar una expectativa de negocio incumplida. B mantiene visible el trabajo hasta conocer su desenlace.
Una consulta de estado correcta puede mostrar un fallo
Nuestra API de ejemplo devuelve HTTP 200 al leer correctamente el recurso de estado, con este contenido:
{"jobId":"J-73","status":"failed","error":{"code":"template-not-found"}}La consulta ha funcionado; la creación del informe ha fallado. Los nombres de campo y el diseño de respuesta son reglas de nuestro ejemplo, no requisitos para todas las API. Una evaluación que solo cuenta llamadas HTTP correctas podría pasar por alto este trabajo. Solicitudes aceptadas, informes terminados y trabajos fallidos responden a preguntas diferentes.
Si la propia consulta de estado no está disponible, el estado actual del trabajo sigue siendo desconocido. El portal no debe deducir que el informe está terminado ni que el trabajo ha fallado con certeza. Otro clic también debe relacionarse con el trabajo existente para no agravar la incertidumbre creando solicitudes adicionales.
Cuándo basta con la aceptación
Una función limitada a recibir solicitudes puede cumplir su cometido acordado mediante una aceptación duradera. En ese caso, una confirmación etiquetada como aceptación es adecuada. Del mismo modo, una operación totalmente completada de forma síncrona no necesita otro ciclo de consulta por principio.
El portal de informes tiene otro objetivo: el usuario quiere el archivo. Por ello, la evaluación de la integración debe llegar hasta ese resultado y una gestión de errores trazable. Una primera respuesta rápida es entonces una característica distinta, no la prueba de que haya un informe disponible.
Fuentes
Seguir leyendo
Todos los artículos
APIs e integración con ASES
ERP, CRM y tienda bien conectados