Les architectures d'applications modernes sont en évolution constante. Un endpoint né en API v1 atteint la v3 ; la structure de chemin derrière un monolithe change complètement après une séparation en microservices ; un partenaire B2B est habitué à un schéma d'URL différent ; ou un projet de modernisation impose une nouvelle disposition de chemins. Lorsque chaque changement nécessite de reconfigurer le client ou le backend depuis zéro, le projet cesse d'être une tâche technique et devient un exercice de coordination prolongé.
L'approche classique offre deux mauvaises options. La première consiste à ajouter la prise en charge de nouveaux chemins au backend — maintenir les anciens endpoints tout en écrivant les nouveaux double la complexité du code et la charge de test. La seconde force les clients ou partenaires à migrer vers le nouveau chemin — c'est une friction sociale et opérationnelle, nécessite souvent une renégociation de contrat B2B, attend les mises à jour des applications mobiles et allonge le calendrier de transition.
Le bon modèle consiste à introduire une couche de réécriture contrôlée dans le flux requête-réponse. Cette couche convertit le chemin envoyé par le client en chemin que le backend comprend, et si nécessaire réécrit les chemins internes dans le corps de la réponse vers les chemins externes attendus par le client. Le backend se modernise en interne ; le client ou partenaire continue de travailler avec le schéma d'URL qu'il connaît déjà.
Pour que cette couche soit efficace, trois conditions doivent être remplies. Premièrement, une logique flexible de recherche-remplacement : chemin fixe, substitution de préfixe, préservation de la query string et transformations de chaînes basées sur FX doivent toutes être prises en charge. Deuxièmement, une application conditionnelle : la règle ne doit se déclencher que lorsque le bon Host, méthode, IP, cookie, header ou condition FX correspond — pas sur chaque requête. Troisièmement, un mapping bidirectionnel avec le corps de la réponse : sinon les liens internes que le backend retourne deviennent des URL cassées côté client.
La Réécriture d'URL et de Chemin de TR7 délivre ce modèle : actions set_path, set_pathq et normalize_uri ; patterns FX STRREPLACE / STRREPLACEALL ; application conditionnelle FX/ACL ; et mapping de chemin bidirectionnel via modifyResponse constituent le fondement d'une architecture de remap de chemin backend transparent.
La couche de réécriture d'URL de TR7 construit un pont contrôlé entre les couches d'architecture applicative — allant bien au-delà de la simple substitution de chemin.
Une requête entrante pour `/api/v1/users/123` peut être convertie vers le chemin `/internal/v3/users/123` attendu par le backend. set_path ne change que le chemin ; set_pathq réécrit le chemin et la query string ensemble. Le client continue d'envoyer son URL existante tandis que le backend opère sur la nouvelle architecture.
Lorsqu'une substitution de chemin fixe ne suffit pas, le langage d'expression FX prend le relais. STRREPLACE et STRREPLACEALL transforment des segments spécifiques — préfixe, suffixe ou milieu de chemin — à l'intérieur du chemin. Les opérateurs peuvent composer des variables, des champs de recherche-remplacement et des conditions dans le même modèle de règle.
Chaque règle de réécriture peut être délimitée par une condition FX/ACL. La règle ne se déclenche que sur un Host, méthode, IP source, cookie, header ou valeur de variable FX correspondant. Différentes transformations de chemin avec différentes conditions peuvent s'exécuter en parallèle sous le même vService.
Modifier uniquement le chemin de la requête est souvent insuffisant — le backend peut retourner des chemins internes dans le corps de la réponse. Avec modifyResponse, les liens HTML, les champs JSON href ou tout texte contenant des chemins internes sont réécrits au format de chemin externe. Le résultat est une architecture de remap de chemin backend entièrement transparente du point de vue du client.
La réécriture de chemin URL n'est pas une action unique — c'est le bloc fondateur pour les patterns de migration, de compatibilité et de masquage de chemin bidirectionnel.
set_path remplace la portion de chemin de la requête entrante par une nouvelle valeur de chemin. La nouvelle valeur peut être écrite statiquement ou rendue dynamique en utilisant des variables de contenu intelligent telles que `%HOST`, `%PATH`, `%METHOD` ou `%SRCIP`. La query string n'est pas préservée lorsque set_path est utilisé ; si les données de query doivent être conservées, set_pathq est préféré. Cette action est utilisée pour mapper une ancienne structure d'URL externe vers une nouvelle disposition de service interne.
set_pathq gère le chemin et la query string dans une seule action de réécriture. Les opérateurs peuvent inclure la valeur `%QUERY` existante dans le nouveau chemin pour préserver les paramètres envoyés par le client. De nouveaux paramètres peuvent également être ajoutés — par exemple, la requête `/api/v1/users?id=42` peut être transformée en `/internal/v3/users?id=42&version=v3-from-v1`. C'est un mécanisme de transition pratique pour le versionnage des API et la compatibilité partenaire.
normalize_uri normalise le chemin et les composants URI vers une forme standard. Les options incluent la fusion de multiples slashes, la suppression des segments point, la résolution des traversées `../`, le décodage des caractères sûrs selon RFC 3986, la mise en majuscule des séquences percent-encodées, la gestion des fragments et le tri alphabétique des paramètres de query. Cette normalisation est importante pour la cohérence des clés de cache, la lisibilité des audits et la résilience contre les tentatives de contournement de sécurité. Elle aide également le WAAP et les autres contrôles de sécurité à prendre des décisions sur le même chemin canonique.
STRREPLACE remplace la première correspondance ; STRREPLACEALL remplace chaque correspondance. Les opérateurs peuvent écrire des expressions telles que `%PATH.STRREPLACE("/old/", "/new/")` pour transformer des segments spécifiques à l'intérieur du chemin. Cette approche gère la substitution de préfixe, le remplacement de segment en milieu de chemin et le déplacement de segments d'URL legacy vers une nouvelle disposition de service. Les champs d'aide de l'interface rendent la saisie des valeurs de recherche et de remplacement plus contrôlée.
Chaque règle de réécriture de chemin peut s'exécuter conditionnellement. La condition peut être une correspondance de header Host, une contrainte de méthode HTTP, une vérification de plage IP source, une comparaison de valeur de cookie ou de header, ou toute expression vraie/fausse produite par le moteur FX. Sous le même vService, des transformations de chemin spécifiques aux partenaires, aux tenants ou aux méthodes peuvent coexister avec différentes conditions. Les requêtes qui ne correspondent pas continuent dans le flux normal sans être affectées.
Lorsque set_path ou set_pathq convertit le chemin de la requête en chemin interne, le backend peut retourner des chemins internes dans le corps de la réponse. Le mode replace de modifyResponse réécrit ces chemins internes au format externe. Par exemple : le client demande `/api/v1/orders`, le backend travaille avec `/internal/orders`, et `"href":"/internal/users/42"` dans le JSON de réponse est retourné en `"href":"/api/v1/users/42"`. Le client opère sans jamais voir la vraie structure d'URL du backend.
modifyResponse n'est pas limité au remap de chemin — il prend en charge différentes transformations sur le corps de réponse. Le mode replace correspond à des patterns regex ou texte brut et les substitue, en faisant le principal outil pour le remap de chemin. Le mode htmlTag injecte du contenu contrôlé dans les balises HTML. Le mode mask masque les données sensibles. Dans le contexte de la Réécriture d'URL et de Chemin, cette capacité est positionnée spécifiquement pour le mapping de chemin bidirectionnel.
La réécriture de chemin est appliquée dans la phase de requête avant que les contrôles de sécurité en aval évaluent la requête. Cela signifie que le virtual patching, la correspondance de signature WAAP, les clés de rate limiting et les règles de trafic opèrent tous sur le chemin réécrit. Le chemin normalisé ou réorganisé devient l'entrée commune pour chaque couche de décision ultérieure. L'écart entre l'URL externe et le chemin de service interne ne produit plus d'incohérence de politique.
La transformation de chemin doit être observable opérationnellement. TR7 peut transporter le chemin original de la requête et la valeur du chemin réécrit dans le flux d'audit et de journalisation. Côté SIEM, la question « quel chemin le client a-t-il demandé, quel chemin le système a-t-il envoyé au backend ? » devient répondable. Cette visibilité est critique lors des projets de migration et des revues de sécurité.
Plusieurs règles de chemin peuvent s'exécuter en séquence sous le même vService. La première règle normalise l'URI, la deuxième effectue une substitution de préfixe, et la troisième enrichit la query string ou ajoute un suffixe sous une condition spécifique. Chaque règle opère sur la sortie de la précédente. Ce modèle permet une chaîne de transformation lisible, testable et incrémentale au lieu d'une seule règle volumineuse et risquée.
La réécriture de chemin URL est opérée conjointement avec les variables de contenu intelligent, l'intégration FX, le langage de condition, les caractéristiques de performance, le comportement d'erreur et le pattern de réécriture de réponse.
La définition du nouveau chemin peut utiliser `%PATH`, `%QUERY`, `%HOST`, `%METHOD`, `%SRCIP`, `%PORT` et des variables personnalisées. Ces variables sont composées dans le champ de valeur des actions set_path et set_pathq pour produire un chemin dynamique. Les fonctions FX peuvent être appliquées à n'importe laquelle de ces variables.
La réécriture de chemin URL est l'un des consommateurs du moteur d'expression FX de TR7. Les opérateurs n'apprennent pas un langage séparé pour la transformation de chemin — ils utilisent STRREPLACE, STRREPLACEALL et d'autres fonctions FX dans la même logique d'expression. Ce modèle partagé fournit une approche de gestion cohérente à travers les règles de trafic, les templates de journalisation et les définitions de conditions.
Les conditions FX/ACL réduisent la portée de la réécriture. Des expressions telles que `%HOST == "partner.example.com"`, `%METHOD in ["POST","PUT"]`, `%SRCIP in MAP_IP("partner_ips")` ou `%HEADER("X-Tenant") == "tenant-a"` sont toutes valides. Plusieurs conditions peuvent être combinées avec une logique AND / OR.
La réécriture de chemin ajoute une faible surcharge par requête ; les transformations basées sur des chaînes ne nécessitent pas d'opérations de socket ou de lecture de fichier supplémentaires. STRREPLACE et STRREPLACEALL s'exécutent en mémoire. La réécriture du corps de réponse est plus coûteuse car elle peut nécessiter la mise en buffer du corps et le traitement regex, il convient donc de ne l'utiliser que là où les scénarios de remap de chemin le requièrent vraiment.
Si une erreur de parsing FX, une variable manquante ou une incompatibilité regex se produit lors de la réécriture, la requête peut continuer dans le flux normal via un fallback sécurisé — elle n'est pas abandonnée. L'erreur est écrite dans le journal d'audit afin que l'opérateur puisse investiguer le problème de configuration ultérieurement. Ce comportement protège l'accès en production d'être interrompu par une règle mal configurée.
Le pattern recommandé pour le remap de chemin transparent comporte deux parties : côté requête, le chemin externe est converti en chemin interne ; côté réponse, les chemins internes dans le corps de réponse sont réécrits en chemins externes. Ces deux règles s'exécutent en tandem sous le même vService. Ce pattern devient la structure standard pour les scénarios de passerelle API, les intégrations partenaires B2B et les projets de migration monolithe-vers-microservices.
Les clients existants continuent d'utiliser les endpoints `/api/v1/...` pendant que TR7 convertit la requête en interne vers la structure `/api/v3/...`. Les liens v3 dans le corps de réponse sont réécrits au format v1 via modifyResponse. Le backend moderne est activé sans aucun changement de code côté client.
Un partenaire peut avoir utilisé le schéma d'URL `/services/payments/...` pendant des années tandis que l'équipe interne est passée à `/v2/payment-api/...`. Une règle set_path spécifique au partenaire, délimitée au header Host du partenaire, gère la traduction. Le partenaire continue de travailler avec l'ancienne URL ; la nouvelle architecture de service tourne en interne.
Un monolithe legacy sert les chemins `/app/orders`, `/app/users` et `/app/inventory`, chacun étant déplacé vers un service backend séparé. TR7 applique le routage basé sur les préfixes et le remap de chemin sans exposer la séparation aux clients. Les utilisateurs conservent le même schéma d'URL pendant que les services sont séparés en arrière-plan.
Un attaquant peut essayer des chemins percent-encodés, des traversées de segments point ou la confusion de slashes pour contourner la correspondance de signature WAAP. normalize_uri amène le chemin en forme canonique, et les contrôles WAAP ultérieurs opèrent sur cette valeur nettoyée. Les variantes d'URL écrites différemment mais ciblant la même ressource sont évaluées de manière plus cohérente.
Versionnage d'API, compatibilité partenaire B2B et remap de chemin backend transparent — laissez-nous vous présenter une mise en place en direct sur vos propres services.