Configurar plantillas Jinja para códigos de respuesta HTTP (custom status codes)

Configurar plantillas Jinja para códigos de respuesta HTTP (custom status codes)

Descripción general

Los Status Code Templates permiten definir dinámicamente el código de estado HTTP que retornará un método en función del resultado de su ejecución. Esta funcionalidad se configura desde la vista de edición del método y utiliza plantillas escritas en Jinja para evaluar condiciones basadas en la respuesta generada.

Objetivo

El propósito de esta funcionalidad es otorgar control preciso sobre los códigos de respuesta HTTP, permitiendo alinear la semántica del protocolo con la lógica de negocio del método.

Funcionamiento

• La plantilla se evalúa al finalizar la ejecución del método.
• Debe devolver una constante válida de status HTTP. Estos códigos se encuentran disponibles en la ventana del editor.
• Solo se evalúa cuando la salida proviene de la plantilla estándar.
• Si la salida proviene de una plantilla de error, la plantilla de status no se ejecuta.













Comportamiento por defecto

Si no se selecciona una plantilla de status code, el método mantiene su comportamiento original, donde el código HTTP se determina automáticamente según el tipo de operación y resultado.

Reglas de implementación

• La plantilla debe devolver exactamente una constante HTTP válida.
• No debe incluir texto adicional.
• Se recomienda mantener condiciones claras y legibles.
• El editor valida la sintaxis antes de guardar.













Ejemplo básico

  1. {% if result.data.0.0 == "success" %}
  2.   HTTP_STATUS_201
  3. {% else %}
  4.   HTTP_STATUS_403
  5. {% endif %}

Ejemplo con validación de errores

  1. {% if result.errors | length > 0 %}
  2.   HTTP_STATUS_400
  3. {% else %}
  4.   HTTP_STATUS_200
  5. {% endif %}

Recomendaciones

• Utilizar lógica simple y mantenible.
• Documentar condiciones complejas.
• Validar plantillas en entornos de prueba.
• Mantener coherencia con estándares REST.

Ventajas

• Mayor control sobre respuestas HTTP.
• Consistencia en APIs.
• Flexibilidad ante escenarios dinámicos.
• Mejor integración con lógica de negocio.

Mapear o trasladar los códigos del origen de datos

Además de la plantilla de status code, que decide el código de las respuestas exitosas, el bloque Plantillas de error del método define qué código HTTP recibe el cliente cuando algo falla. Dos opciones excluyentes lo gobiernan:

Opciones Trasladar el código HTTP de respuesta del origen de datos y Mapear códigos HTTP en el bloque Plantillas de error
  • Mapear códigos HTTP (opción por defecto): cada error tiene su tarjeta, con una Plantilla y un Código de respuesta elegibles. Están los errores propios de Vortex (ERROR GENÉRICO, ERROR DE VALIDACIÓN DE PARÁMETRO, ERROR FUERA DE SERVICIO) y los del motor: 204 NO DATA FOUND, 206 PARTIAL CONTENT, 401, 404, 408 REQUEST ACCEPTED, 409 PIPELINE RESPONSE, 500 y 502 WEBSERVICE RESPONSE ERROR. Si no elige código, se usa el del error; 408 y 409 responden siempre 202.
  • Trasladar el código HTTP de respuesta del origen de datos: cuando el origen es un servicio web y responde con error, el cliente recibe el mismo código que devolvió el origen, por ejemplo 404 o 500. Con esta opción los códigos mapeados para los errores del motor se descartan; solo se conservan los de ERROR GENÉRICO, ERROR DE VALIDACIÓN DE PARÁMETRO y ERROR FUERA DE SERVICIO. La plantilla que se usa sigue siendo la del error 502, que es como el motor reporta la falla del origen.

Las plantillas de error se eligen por formato de salida y reciben result.error_code, result.error_message, result.fields.statusCode, result.fields.reason y result.fields.content con la respuesta del origen, además de request.traceid. Si un error no tiene plantilla, se usa la de ERROR GENÉRICO del método; si tampoco existe, la de la cuenta.

Artículos relacionados