Ejercicio del nodo HTTP Request de n8n: enrutar respuestas y limitar el sondeo
Practica cómo inspeccionar respuestas del nodo HTTP Request de n8n, enrutar casos controlados y diseñar un sondeo con salidas de finalización y escalado.
Comprobado con las fuentes citadas el .
Ejercicio editorial: tarea, requisitos previos y entradas
Utiliza el nodo HTTP Request de n8n para inspeccionar respuestas controladas y después diseña un flujo de sondeo que distinga entre trabajo completado, trabajo pendiente y escalado. Este es un ejercicio editorial: el flujo propuesto no se ha ejecutado ni validado. Los entregables son un flujo de enrutamiento de respuestas, un diseño de sondeo y evidencias que expliquen cada vía de salida.
Necesitas tu propio entorno de n8n, conocimientos básicos de API y endpoints controlados proporcionados por quien imparta el ejercicio. Esta persona debe facilitar los métodos de solicitud, las cabeceras, los cuerpos y las secuencias de respuesta que se describen a continuación; este artículo no proporciona un servidor de casos de prueba. Utiliza entradas sintéticas y deja los datos de la empresa fuera del ejercicio.
Trata estos casos de prueba como contratos definidos para el ejercicio, no como una semántica HTTP universal. La guía Asynchronous Request-Reply de Microsoft distingue entre una confirmación inicial con 202 y una solicitud de estado que devuelve 200 mientras el trabajo sigue pendiente. Define la finalización a partir del estado documentado del caso de prueba, en lugar de basarte únicamente en su código de estado.
| Caso de prueba | Secuencia de respuestas definida | Resultado esperado |
|---|---|---|
| Finalización inmediata | 200 con estado completed | Completado |
| Trabajo asíncrono | 202, después 200 pending y después 200 completed | Sondear y después completar |
| Respuesta vacía | 204 sin cuerpo, definido como completado | Completar sin leer un cuerpo de resultado |
| Nunca se completa | 202 y después 200 pending repetidos | Escalar al alcanzar el límite |
Creemos que la habilidad útil aquí consiste en explicar por qué existe una rama antes de añadir más nodos. Un diagrama del flujo debe permitir que otro desarrollador entienda sus decisiones de parada.
Sources: Asynchronous Request-Reply Pattern - Azure Architecture Center | Microsoft Learn
Inspecciona la respuesta del nodo HTTP Request de n8n
Activa Include Response Headers and Status. La documentación de HTTP Request de n8n indica que esta opción devuelve las cabeceras y el código de estado junto con el cuerpo. Inspecciona la salida real de cada caso de prueba antes de escribir expresiones de enrutamiento y registra el estado devuelto, las cabeceras disponibles y la estructura del cuerpo.
Para el enrutamiento posterior, utiliza los campos devueltos en esa salida. La referencia de expresiones de n8n limita $response.statusCode al nodo HTTP Request; no des por hecho que esa expresión está disponible en nodos posteriores. La secuencia de inspección sugerida a continuación mantiene el contrato de respuesta separado de las suposiciones sobre las rutas de los campos.
- Ejecuta cada caso de prueba proporcionado y guarda la estructura de salida observada.
- Identifica el campo de estado devuelto y cualquier campo de estado documentado en el cuerpo.
- Escribe una regla de enrutamiento para cada caso de prueba antes de conectar las ramas.
- Dirige cualquier código de estado o estado del trabajo inesperado al escalado e indica el motivo.
Registra las cabeceras de ubicación de sondeo o de espera que proporcione el caso de prueba, pero no las utilices para controlar el bucle de este ejercicio. El sondeo basado en cabeceras, la gestión de cabeceras ausentes y la interpretación de tiempos de espera necesitan su propia especificación de implementación. Utiliza en su lugar un endpoint de sondeo indicado por quien imparta el ejercicio y un intervalo fijo para el ejercicio.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/README.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/transform-data/expression-reference/httpresponse.md at main · n8n-io/n8n-docs · GitHub
Diseña el sondeo con vías de salida separadas
Para el diseño de sondeo con el nodo HTTP Request de n8n, define un límite antes de empezar. Como restricción editorial, permite un máximo de tres solicitudes de estado después de la confirmación inicial; esto no es un valor predeterminado para el funcionamiento habitual. Conserva un identificador de operación, el número de sondeos realizados, el límite, la última respuesta y el motivo de parada. Entrega un diseño de sondeo anotado; este artículo no proporciona una implementación de bucle lista para copiar.
La referencia oficial de bucles de n8n exige una terminación explícita y un límite del índice de ejecución para el sondeo en modo reset, y describe las conexiones de salida de Loop Over Items typeVersion 3. Para este diseño editorial, especifica un único nodo de decisión posterior a la respuesta que se evalúe una vez por cada respuesta de estado: sus valores de $runIndex, que empiezan en cero, 0, 1 y 2 corresponden a las solicitudes uno, dos y tres. Comprueba primero la finalización; en caso contrario, escala el trabajo pendiente cuando $runIndex sea como mínimo 2. Antes de volver a solicitar el estado, la comprobación independiente del margen disponible debe rechazar un número de sondeos realizados de 3 o más.
Estas comprobaciones describen el mismo máximo de tres solicitudes, no dos presupuestos independientes. Su configuración ejecutable y la conservación del estado quedan fuera de las instrucciones de implementación de este ejercicio. La documentación de Wait de n8n permite establecer un intervalo mediante Wait Amount y Wait Unit; su opción Limit Wait Time, específica de webhooks, no es un plazo límite para un bucle de sondeo.
Utiliza la siguiente secuencia de decisión sugerida. Recorre las respuestas pending, pending, completed y pending, pending, pending, registrando el número de cada solicitud, el índice de ejecución del nodo de decisión y el destino.
Mantendríamos la primera versión limitada a un máximo de solicitudes y un intervalo fijo. En nuestra opinión, hacer que esas salidas se puedan inspeccionar resulta más útil que añadir cálculos de plazos antes de que el contrato de estado esté claro.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.wait.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-loops-official/references/LOOP_OVER_ITEMS.md at main · n8n-io/skills · GitHub
Criterios de finalización y reflexión
Para el ejercicio del nodo HTTP Request de n8n, entrega el flujo de enrutamiento, las salidas guardadas de los casos de prueba y el diseño de sondeo anotado. Si también implementas el bucle, demuestra cómo se conservan su identificador de operación y su contador tras cada respuesta HTTP. Utiliza esta lista de comprobación sugerida para revisar la entrega.
Este ejercicio no especifica una corrección propia de una versión concreta para los fallos al interpretar cuerpos vacíos; si se produce uno, registra la versión instalada, la configuración del formato de respuesta y el fallo, en lugar de considerar una solución provisional no verificada como la solución.
Como reflexión, explica por qué una solicitud de estado correcta puede seguir representando trabajo pendiente, qué campos deben conservarse para la siguiente solicitud y justifica tu decisión ante la respuesta final. Un posible esquema de solución tiene cuatro destinos distintos: finalización inmediata, finalización tras el sondeo, continuación del sondeo y escalado.
Sources: Asynchronous Request-Reply Pattern - Azure Architecture Center | Microsoft Learn
