Las arquitecturas de aplicaciones modernas están en constante evolución. Un endpoint nacido como API v1 llega a v3; la estructura de path detrás de un monolito cambia completamente tras una división en microservicios; un socio B2B está acostumbrado a un esquema de URL diferente; o un proyecto de modernización impone un nuevo layout de path. Cuando cada cambio requiere reconfigurar el cliente o el backend desde cero, el proyecto deja de ser una tarea técnica y se convierte en un largo ejercicio de coordinación.
El enfoque clásico ofrece dos malas opciones. La primera es añadir soporte de nuevos paths al backend — mantener endpoints antiguos mientras se escriben nuevos duplica la complejidad del código y la carga de pruebas. La segunda es obligar a los clientes o socios a migrar al nuevo path — esto supone fricción social y operacional, a menudo requiere renegociación de contratos B2B, espera actualizaciones de aplicaciones móviles y alarga el cronograma de transición.
El modelo correcto es introducir una capa de reescritura controlada en el flujo solicitud-respuesta. Esta capa convierte el path que envía el cliente en el path que entiende el backend y, si es necesario, reescribe los paths internos del cuerpo de respuesta a los paths externos que espera el cliente. El backend se moderniza internamente; el cliente o socio sigue trabajando con el esquema de URL que ya conoce.
Para que esta capa sea efectiva, se deben cumplir tres condiciones. Primero, lógica flexible de búsqueda y sustitución: deben soportarse path fijo, sustitución de prefijo, preservación de query y transformaciones de cadenas basadas en FX. Segundo, aplicación condicional: la regla debe activarse solo cuando coincida el Host, método, IP, cookie, header o condición FX correctos — no en cada solicitud. Tercero, mapeo bidireccional con el cuerpo de respuesta: de lo contrario, los enlaces internos que devuelve el backend se convierten en URLs rotas en el lado del cliente.
TR7 Reescritura de URL y Path entrega este modelo: acciones set_path, set_pathq y normalize_uri; patrones FX STRREPLACE / STRREPLACEALL; aplicación condicional FX/ACL; y mapeo bidireccional de paths mediante modifyResponse forman la base de una arquitectura de remap transparente de backend.
La capa de reescritura de URL de TR7 construye un puente controlado entre capas de arquitectura de aplicaciones — yendo mucho más allá de la simple sustitución de paths.
Una solicitud entrante para `/api/v1/users/123` puede convertirse al path `/internal/v3/users/123` que espera el backend. set_path cambia solo el path; set_pathq reescribe path y query string juntos. El cliente sigue enviando su URL existente mientras el backend opera con la nueva arquitectura.
Cuando una sustitución de path fijo no es suficiente, el lenguaje de expresión FX toma el control. STRREPLACE y STRREPLACEALL transforman segmentos específicos — prefijo, sufijo o segmento intermedio del path — dentro del path. Los operadores pueden combinar variables, campos de búsqueda y sustitución, y condiciones dentro del mismo modelo de reglas.
Cada regla de reescritura puede delimitarse con una condición FX/ACL. La regla se activa solo en un Host, método, IP de origen, cookie, header o valor de variable FX coincidente. Diferentes transformaciones de path con diferentes condiciones pueden ejecutarse en paralelo bajo el mismo vService.
Cambiar el path de la solicitud a menudo no es suficiente por sí solo — el backend puede devolver paths internos en el cuerpo de respuesta. Con modifyResponse, los enlaces HTML, los campos JSON href o cualquier texto que contenga paths internos se reescribe de vuelta al formato de path externo. El resultado es una arquitectura de remap transparente de backend completamente transparente desde la perspectiva del cliente.
La reescritura de path URL no es una única acción — es el bloque de construcción fundamental para patrones de migración, compatibilidad y ocultación bidireccional de paths.
set_path reemplaza la porción de path de la solicitud entrante con un nuevo valor de path. El nuevo valor puede escribirse estáticamente o hacerse dinámico usando variables de contenido inteligente como `%HOST`, `%PATH`, `%METHOD` o `%SRCIP`. La query string no se preserva cuando se usa set_path; si se deben retener los datos de query, se prefiere set_pathq. Esta acción se usa para mapear una estructura de URL externa antigua a un nuevo layout de servicio interno.
set_pathq gestiona path y query string en una única acción de reescritura. Los operadores pueden incluir el valor existente `%QUERY` en el nuevo path para preservar los parámetros que envió el cliente. También pueden añadirse nuevos parámetros — por ejemplo, la solicitud `/api/v1/users?id=42` puede transformarse a `/internal/v3/users?id=42&version=v3-from-v1`. Este es un mecanismo de transición práctico para API versioning y compatibilidad con socios.
normalize_uri normaliza el path y los componentes URI a una forma estándar. Las opciones incluyen fusionar múltiples barras, eliminar segmentos de puntos, resolver traversals `../`, decodificar caracteres seguros según RFC 3986, convertir a mayúsculas las secuencias con codificación de porcentaje, manejar fragmentos y ordenar los parámetros de query alfabéticamente. Esta normalización es importante para la consistencia de la clave de caché, la legibilidad de auditoría y la resiliencia contra intentos de evasión de seguridad. También ayuda a que WAAP y otros controles de seguridad tomen decisiones sobre el mismo path canónico.
STRREPLACE reemplaza la primera coincidencia; STRREPLACEALL reemplaza cada coincidencia. Los operadores pueden escribir expresiones como `%PATH.STRREPLACE("/old/", "/new/")` para transformar segmentos específicos dentro del path. Este enfoque maneja la sustitución de prefijo, el reemplazo de segmentos intermedios y el traslado de segmentos de URL heredados a un nuevo layout de servicio. Los campos de ayuda en la UI hacen que la introducción de valores de búsqueda y sustitución sea más controlada.
Cada regla de reescritura de path puede ejecutarse condicionalmente. La condición puede ser una coincidencia de header Host, una restricción de método HTTP, una comprobación de rango de IP de origen, una comparación de valor de cookie o header, o cualquier expresión verdadero/falso producida por el motor FX. Bajo el mismo vService, transformaciones de path específicas para socios, tenants o métodos pueden coexistir con diferentes condiciones. Las solicitudes que no coinciden continúan por el flujo normal sin verse afectadas.
Cuando set_path o set_pathq convierte el path de solicitud a un path interno, el backend puede devolver paths internos en el cuerpo de respuesta. El modo replace de modifyResponse reescribe esos paths internos de vuelta al formato externo. Por ejemplo: el cliente solicita `/api/v1/orders`, el backend trabaja con `/internal/orders`, y `"href":"/internal/users/42"` en el JSON de respuesta se devuelve como `"href":"/api/v1/users/42"`. El cliente opera sin ver nunca la estructura de URL real del backend.
modifyResponse no se limita al remap de paths — soporta diferentes transformaciones en el cuerpo de respuesta. El modo replace coincide con patrones regex o texto plano y los sustituye, convirtiéndolo en la herramienta principal para el remap de paths. El modo htmlTag inyecta contenido controlado en etiquetas HTML. El modo mask oculta datos sensibles. En el contexto de Reescritura de URL y Path, esta capacidad se posiciona específicamente para el mapeo bidireccional de paths.
La reescritura de path se aplica en la fase de solicitud antes de que los controles de seguridad posteriores evalúen la solicitud. Esto significa que virtual patching, coincidencia de firmas WAAP, claves de rate-limiting y reglas de tráfico operan todas sobre el path reescrito. El path normalizado o reorganizado se convierte en la entrada común para cada capa de decisión posterior. La diferencia entre la URL externa y el path de servicio interno ya no produce inconsistencia de política.
La transformación de path debe ser observable operacionalmente. TR7 puede llevar el path de solicitud original y el valor del path reescrito al flujo de auditoría y log. En el lado del SIEM, la pregunta "¿qué path solicitó el cliente, qué path envió el sistema al backend?" se vuelve respondible. Esta visibilidad es crítica durante proyectos de migración y revisiones de seguridad.
Múltiples reglas de path pueden ejecutarse en secuencia bajo el mismo vService. La primera regla normaliza la URI, la segunda realiza una sustitución de prefijo, y la tercera enriquece la query string o añade un sufijo bajo una condición específica. Cada regla opera sobre la salida de la anterior. Este modelo permite una cadena de transformación legible, testeable e incremental en lugar de una regla única grande y arriesgada.
La reescritura de path URL se opera junto con variables de contenido inteligente, integración FX, el lenguaje de condiciones, características de rendimiento, comportamiento de errores y el patrón de reescritura de respuesta.
La nueva definición de path puede usar `%PATH`, `%QUERY`, `%HOST`, `%METHOD`, `%SRCIP`, `%PORT` y variables personalizadas. Estas variables se componen en el campo de valor de las acciones set_path y set_pathq para producir un path dinámico. Las funciones FX pueden aplicarse a cualquiera de estas variables.
La reescritura de path URL es uno de los consumidores del motor de expresión FX de TR7. Los operadores no aprenden un lenguaje separado para la transformación de paths — usan STRREPLACE, STRREPLACEALL y otras funciones FX dentro de la misma lógica de expresión. Este modelo compartido proporciona un enfoque de gestión consistente a través de reglas de tráfico, plantillas de log y definiciones de condiciones.
Las condiciones FX/ACL limitan el alcance de la reescritura. Expresiones como `%HOST == "partner.example.com"`, `%METHOD in ["POST","PUT"]`, `%SRCIP in MAP_IP("partner_ips")` o `%HEADER("X-Tenant") == "tenant-a"` son todas válidas. Múltiples condiciones pueden combinarse con lógica AND / OR.
La reescritura de path añade un bajo overhead por solicitud; las transformaciones basadas en cadenas no requieren operaciones adicionales de socket o lectura de archivos. STRREPLACE y STRREPLACEALL se ejecutan en memoria. La reescritura del cuerpo de respuesta es más costosa porque puede requerir buffering del cuerpo y procesamiento regex, por lo que debe usarse solo donde los escenarios de remap de path genuinamente lo requieran.
Si ocurre un error de parseo FX, variable faltante o discrepancia de regex durante la reescritura, la solicitud puede continuar por el flujo normal mediante un fallback seguro — no se descarta. El error se escribe en el log de auditoría para que el operador pueda investigar el problema de configuración más tarde. Este comportamiento protege el acceso a producción de ser interrumpido por una regla mal configurada.
El patrón recomendado para el remap transparente de paths tiene dos partes: en el lado de la solicitud, el path externo se convierte al path interno; en el lado de la respuesta, los paths internos del cuerpo de respuesta se reescriben a paths externos. Estas dos reglas se ejecutan como un par coincidente bajo el mismo vService. Este patrón se convierte en la estructura estándar para escenarios de API gateway, integraciones de socios B2B y proyectos de migración de monolito a microservicios.
Los clientes existentes siguen usando endpoints `/api/v1/...` mientras TR7 convierte la solicitud internamente a la estructura `/api/v3/...`. Los enlaces v3 del cuerpo de respuesta se reescriben de vuelta al formato v1 mediante modifyResponse. El backend moderno se activa sin ningún cambio en el código del cliente.
Un socio puede haber usado el esquema de URL `/services/payments/...` durante años mientras el equipo interno ha pasado a `/v2/payment-api/...`. Una regla set_path específica para socios, delimitada al header Host del socio, gestiona la traducción. El socio sigue trabajando con la URL antigua; la nueva arquitectura de servicio opera por dentro.
Un monolito heredado sirve paths `/app/orders`, `/app/users` y `/app/inventory`, cada uno de los cuales se está trasladando a un servicio backend separado. TR7 aplica enrutamiento basado en prefijo y remap de paths sin exponer la división a los clientes. Los usuarios conservan el mismo esquema de URL mientras los servicios se separan en segundo plano.
Un atacante puede intentar paths con codificación de porcentaje, traversals de segmentos de puntos o confusión de barras para evadir la coincidencia de firmas WAAP. normalize_uri lleva el path a forma canónica, y los controles WAAP posteriores operan sobre este valor limpio. Las variantes de URL que se escriben de manera diferente pero apuntan al mismo recurso se evalúan de forma más consistente.
API versioning, compatibilidad de URL para socios B2B y remap transparente de backend — déjenos guiarle por una configuración en vivo sobre sus propios servicios.