Plantillas jinja para definir códigos de respuesta HTTP (custom status codes)

Plantillas jinja para definir 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.

    • Related Articles

    • Cómo definir respuestas de error personalizadas

      Resumen Así como puedes definir formatos y plantillas para las respuestas exitosas de la solicitud al método, puedes definir plantillas de error para cada formato que hayas agregado y para cada tipo de error conocido. Configurar plantillas de error ...

    • Cómo trabajar con las plantillas para definir la salida de los métodos

      Resumen Las plantillas de salida o output permiten definir cómo será la respuesta entregada al ejecutar un método de la API. Las plantillas se relacionan a formatos de salida. Configurar plantillas Para definir una nueva salida seleccione el formato ...

    • Cómo definir formatos de respuesta de los métodos

      Resumen Los formatos de salida permiten definir uno o más formatos de respuesta en los métodos de su API. Los formatos de salida pueden ser mútiples en formato JSON, aunque también puede exponer los datos en CSV y XML. Configurar formatos Al crear un ...

    • Orígenes de datos desde servicios web REST/json

      Resumen El conector a servicios web REST/JSON ofrece todas las capacidades necesarias para conectarse a este tipo de orígenes. Esta opción permite recolectar datos desde servicios web REST/JSON o configurar acciones de escritura, para luego crear ...

    • Qué es una vista de datos

      Resumen La plataforma no requiere de un proceso ETL off-line para extraer los datos desde los orígenes, sino que asociadas a la vista se encuentran un conjunto de reglas que el motor de datos interpreta para consultar la fuente a demanda o ...