Cross Segmentos - TOTVS Backoffice (Línea Protheus) MI - Configurador (SIGACFG) - Rest 2.0

Tiempo aproximado de lectura: 00:05:00 min

Duda
Que es el Rest 2.0?

Ambiente
Cross Segmentos - TOTVS Backoffice (Línea Protheus) MI - Configurador (SIGACFG) - Rest 2.0 - A partir de la versión 12

Solución

Llamamos REST 2.0 al modelo que reemplazará a REST ADVPL y es mantenido por los equipos de Tecnología y Framework , dependiendo solo de dónde ocurre la situación reportada, es decir, en qué capa ocurre.

Este modelo utiliza las capas:

• Aceptar de binario
• control tlppCore
• Negocio híbrido:
• API ADVPL con clases WSRESTFul, para mantener la compatibilidad.
• API TLPP con anotaciones, para nuevas API modernas.

El detalle aquí es que, independientemente del tipo de API, los recursos del entorno precargados, la autenticación de Protheus y los modelos de licencia están disponibles.

El objetivo es obtener todos los beneficios del modelo más moderno, pero también mantener la mayor compatibilidad posible para no romper nada de lo que ya está construido. Sin embargo, algunos pequeños cambios de comportamiento son necesarios para no afectar el rendimiento o la facilidad de evolución de los recursos. Algunos cambios que se mapean:

• 404 Página no encontrada en HTML en lugar de Json;
• Las barras diagonales adicionales en la dirección de solicitud ya no se ignoran y provocan una devolución de estado 404;
• La versión 2 de SSL (clave SSL2) está descontinuada.
• Algunos encabezados informativos como FWRESTBUILD que ya no se envía.
• El mecanismo que mantuvo la capa de aceptación en ejecución ya no se repite en un subproceso ADVPL. Ahora ejecuta cada ciclo de actualización del [ONSTART] del AppServer y finaliza la ejecución después de asegurarse de que el servicio de aceptación está respondiendo. Este cambio hace que se escriban mensajes adicionales en la consola, lo que indica que el trabajo se ejecutó con frecuencia de actualización. No está relacionado y no requiere ningún cambio de configuración en el archivo ini, simplemente sucedió debido al cambio de arquitectura que sufrió el modelo.

• REST 2.0 ahora siempre devuelve el  encabezado  Content-Type con el valor de codificación utf-8. Si se recibe el encabezado  Aceptar en la solicitud al servidor REST 2.0  , con el contenido charset=cp1522, este será el retorno del tipo de contenido de la solicitud. Ejemplo:

Con el reemplazo de las capas de aceptación y control, ya era posible notar un rendimiento de respuesta de solicitud hasta 3 veces más rápido en comparación con el modelo ADVPL. Sin embargo, es importante recalcar que el tiempo de respuesta depende mucho del tipo de procesamiento que realiza cada API y que la ganancia automática de rendimiento se refiere únicamente al tiempo de preprocesamiento de la solicitud. Con la sustitución paulatina de las API's por las TLPP podremos tener las respuestas aún más performativas, dependiendo únicamente del buen uso del lenguaje y de la arquitectura adoptada en cada API.