Moderne Anwendungsarchitekturen befinden sich in ständiger Evolution. Ein als API v1 geborener Endpoint erreicht v3; die Pfadstruktur hinter einem Monolithen ändert sich nach einem Microservice-Split vollständig; ein B2B-Partner ist an ein anderes URL-Schema gewöhnt; oder ein Modernisierungsprojekt erzwingt ein neues Pfad-Layout. Wenn jede Änderung eine Neukonfiguration von Client oder Backend von Grund auf erfordert, hört das Projekt auf, eine technische Aufgabe zu sein, und wird zu einer langwierigen Koordinationsübung.
Der klassische Ansatz bietet zwei schlechte Optionen. Erstens: neue Pfadunterstützung zum Backend hinzufügen — die Pflege alter Endpoints bei gleichzeitigem Schreiben neuer verdoppelt Codekomplexität und Testaufwand. Zweitens: Clients oder Partner zur Migration auf den neuen Pfad zwingen — das ist sozialer und operativer Aufwand, erfordert oft B2B-Vertragsverhandlungen, wartet auf mobile Anwendungsaktualisierungen und streckt den Übergangszeitplan.
Das richtige Modell besteht darin, eine kontrollierte Umschreibungsschicht im Anfrage-Antwort-Fluss einzuführen. Diese Schicht wandelt den vom Client gesendeten Pfad in den vom Backend verstandenen Pfad um und schreibt bei Bedarf die internen Pfade im Response-Body zurück in die externen Pfade, die der Client erwartet. Das Backend modernisiert intern; der Client oder Partner arbeitet weiterhin mit dem URL-Schema, das er bereits kennt.
Damit diese Schicht wirksam ist, müssen drei Bedingungen erfüllt sein. Erstens: flexible Suchen-und-Ersetzen-Logik — fester Pfad, Präfix-Substitution, Query-Beibehaltung und FX-basierte String-Transformationen müssen alle unterstützt werden. Zweitens: bedingte Anwendung — die Regel darf nur auslösen, wenn der richtige Host, die Methode, IP, Cookie, Header oder FX-Bedingung übereinstimmt, nicht bei jeder Anfrage. Drittens: bidirektionale Abbildung mit dem Response-Body — sonst werden die internen Links, die das Backend zurückgibt, zu defekten URLs auf der Client-Seite.
TR7 URL- und Pfad-Umschreibung liefert dieses Modell: set_path-, set_pathq- und normalize_uri-Aktionen; FX STRREPLACE / STRREPLACEALL-Muster; FX/ACL-bedingte Anwendung; und bidirektionale Pfadabbildung über modifyResponse bilden die Grundlage einer transparenten Backend-Pfad-Remap-Architektur.
TR7s URL-Umschreibungsschicht baut eine kontrollierte Brücke zwischen Anwendungsarchitekturschichten — weit über einfache Pfadsubstitution hinaus.
Eine eingehende Anfrage für `/api/v1/users/123` kann in den `/internal/v3/users/123`-Pfad umgewandelt werden, den das Backend erwartet. set_path ändert nur den Pfad; set_pathq schreibt Pfad und Query-String zusammen um. Der Client sendet weiterhin seine bestehende URL, während das Backend auf der neuen Architektur operiert.
Wenn eine feste Pfadsubstitution nicht ausreicht, übernimmt die FX-Ausdruckssprache. STRREPLACE und STRREPLACEALL transformieren spezifische Segmente — Präfix, Suffix oder Mitte des Pfades — innerhalb des Pfades. Operatoren können Variablen, Suchen-und-Ersetzen-Felder und Bedingungen im selben Regelmodell kombinieren.
Jede Umschreibungsregel kann mit einer FX/ACL-Bedingung abgegrenzt werden. Die Regel wird nur bei einem übereinstimmenden Host, einer Methode, einer Quell-IP, einem Cookie, einem Header oder einem FX-Variablenwert ausgelöst. Verschiedene Pfadtransformationen mit unterschiedlichen Bedingungen können parallel unter demselben vService laufen.
Den Anfragepfad allein zu ändern ist oft nicht genug — das Backend kann interne Pfade im Response-Body zurückgeben. Mit modifyResponse werden HTML-Links, JSON-href-Felder oder beliebiger Text mit internen Pfaden zurück in das externe Pfadformat geschrieben. Das Ergebnis ist eine vollständig transparente Backend-Pfad-Remap-Architektur aus Sicht des Clients.
URL-Pfad-Umschreibung ist keine einzelne Aktion — sie ist der grundlegende Baustein für Migration, Kompatibilität und bidirektionale Pfad-Versteckmuster.
set_path ersetzt den Pfadteil der eingehenden Anfrage durch einen neuen Pfadwert. Der neue Wert kann statisch geschrieben oder mit Smart-Content-Variablen wie `%HOST`, `%PATH`, `%METHOD` oder `%SRCIP` dynamisch gemacht werden. Der Query-String wird bei Verwendung von set_path nicht beibehalten; wenn Query-Daten erhalten bleiben müssen, wird set_pathq bevorzugt. Diese Aktion wird verwendet, um eine alte externe URL-Struktur einem neuen internen Service-Layout zuzuordnen.
set_pathq verwaltet Pfad und Query-String in einer einzigen Umschreibungsaktion. Operatoren können den bestehenden `%QUERY`-Wert in den neuen Pfad einschließen, um die vom Client gesendeten Parameter beizubehalten. Neue Parameter können auch angehängt werden — beispielsweise kann die Anfrage `/api/v1/users?id=42` in `/internal/v3/users?id=42&version=v3-from-v1` transformiert werden. Dies ist ein praktischer Übergangsmechanismus für API-Versionierung und Partnerkompatibilität.
normalize_uri normalisiert den Pfad und URI-Komponenten auf eine Standardform. Optionen umfassen das Zusammenführen mehrerer Schrägstriche, das Entfernen von Dot-Segmenten, die Auflösung von `../`-Traversals, das Dekodieren sicherer Zeichen gemäß RFC 3986, die Großschreibung von Prozent-codierten Sequenzen, die Behandlung von Fragmenten und die alphabetische Sortierung von Query-Parametern. Diese Normalisierung ist wichtig für Cache-Key-Konsistenz, Audit-Lesbarkeit und Widerstandsfähigkeit gegen Sicherheitsumgehungsversuche. Sie hilft auch WAAP und anderen Sicherheitskontrollen, Entscheidungen auf demselben kanonischen Pfad zu treffen.
STRREPLACE ersetzt die erste Übereinstimmung; STRREPLACEALL ersetzt jede Übereinstimmung. Operatoren können Ausdrücke wie `%PATH.STRREPLACE("/old/", "/new/")` schreiben, um bestimmte Segmente im Pfad zu transformieren. Dieser Ansatz behandelt Präfix-Substitution, Segment-Ersatz in der Mitte des Pfades und das Verschieben von Legacy-URL-Segmenten in ein neues Service-Layout. UI-Hilfsfelder machen die Eingabe von Such- und Ersetzungswerten kontrollierbarer.
Jede Pfad-Umschreibungsregel kann bedingt ausgeführt werden. Die Bedingung kann eine Host-Header-Übereinstimmung, eine HTTP-Methodeneinschränkung, eine Quell-IP-Bereichsprüfung, ein Cookie- oder Header-Wertvergleich oder ein beliebiger von der FX-Engine erzeugter Wahr/Falsch-Ausdruck sein. Unter demselben vService können partnerspezifische, mandantenspezifische oder methodenspezifische Pfadtransformationen mit unterschiedlichen Bedingungen koexistieren. Anfragen, die nicht übereinstimmen, fließen unverändert durch den normalen Fluss.
Wenn set_path oder set_pathq den Anfragepfad in einen internen Pfad umwandelt, kann das Backend interne Pfade im Response-Body zurückgeben. Der modifyResponse-Ersetze-Modus schreibt diese internen Pfade zurück in das externe Format. Beispiel: Der Client fordert `/api/v1/orders` an, das Backend arbeitet mit `/internal/orders`, und `"href":"/internal/users/42"` im Response-JSON wird als `"href":"/api/v1/users/42"` zurückgegeben. Der Client operiert ohne je die echte URL-Struktur des Backends zu sehen.
modifyResponse ist nicht auf Pfad-Remap beschränkt — es unterstützt verschiedene Transformationen am Response-Body. Der Ersetze-Modus sucht Regex- oder Klartextmuster und ersetzt sie, was es zum primären Werkzeug für das Pfad-Remap macht. Der htmlTag-Modus injiziert kontrollierten Inhalt in HTML-Tags. Der Mask-Modus verbirgt sensible Daten. Im Kontext von URL- und Pfad-Umschreibung ist diese Fähigkeit speziell für die bidirektionale Pfadabbildung positioniert.
Pfad-Umschreibung wird in der Anfragnphase angewendet, bevor nachgelagerte Sicherheitskontrollen die Anfrage auswerten. Das bedeutet, dass Virtual Patching, WAAP-Signaturabgleich, Rate-Limiting-Schlüssel und Traffic-Regeln alle auf dem umgeschriebenen Pfad operieren. Der normalisierte oder neu angeordnete Pfad wird zum gemeinsamen Input für jede nachfolgende Entscheidungsschicht. Die Lücke zwischen der externen URL und dem internen Service-Pfad erzeugt keine Richtlinieninkonsistenz mehr.
Pfadtransformation muss operativ beobachtbar sein. TR7 kann den ursprünglichen Anfragepfad und den umgeschriebenen Pfadwert in den Audit- und Log-Stream übertragen. Auf der SIEM-Seite wird die Frage "welchen Pfad hat der Client angefordert, welchen Pfad hat das System an das Backend gesendet?" beantwortbar. Diese Sichtbarkeit ist bei Migrationsprojekten und Sicherheitsüberprüfungen kritisch.
Mehrere Pfadregeln können sequenziell unter demselben vService ausgeführt werden. Die erste Regel normalisiert die URI, die zweite führt eine Präfix-Substitution durch, und die dritte reichert den Query-String an oder hängt unter einer bestimmten Bedingung ein Suffix an. Jede Regel operiert auf der Ausgabe der vorherigen. Dieses Modell ermöglicht eine lesbare, testbare und inkrementelle Transformationskette anstatt einer einzelnen großen und riskanten Regel.
URL-Pfad-Umschreibung wird zusammen mit Smart-Content-Variablen, FX-Integration, der Bedingungssprache, Leistungsmerkmalen, Fehlerverhalten und dem Response-Umschreibungsmuster betrieben.
Die neue Pfaddefinition kann `%PATH`, `%QUERY`, `%HOST`, `%METHOD`, `%SRCIP`, `%PORT` und benutzerdefinierte Variablen verwenden. Diese Variablen werden im Wertfeld der set_path- und set_pathq-Aktionen zusammengestellt, um einen dynamischen Pfad zu erzeugen. FX-Funktionen können auf jede dieser Variablen angewendet werden.
URL-Pfad-Umschreibung ist ein Verbraucher der TR7-FX-Ausdrucks-Engine. Operatoren lernen keine separate Sprache für Pfadtransformation — sie verwenden STRREPLACE, STRREPLACEALL und andere FX-Funktionen innerhalb derselben Ausdruckslogik. Dieses gemeinsame Modell sorgt für einen konsistenten Verwaltungsansatz über Traffic-Regeln, Log-Vorlagen und Bedingungsdefinitionen hinweg.
FX/ACL-Bedingungen begrenzen den Umschreibungsbereich. Ausdrücke wie `%HOST == "partner.example.com"`, `%METHOD in ["POST","PUT"]`, `%SRCIP in MAP_IP("partner_ips")` oder `%HEADER("X-Tenant") == "tenant-a"` sind alle gültig. Mehrere Bedingungen können mit AND / OR-Logik kombiniert werden.
Pfad-Umschreibung fügt pro Anfrage einen geringen Zusatzaufwand hinzu; stringbasierte Transformationen erfordern keine zusätzlichen Socket- oder Dateilese-Operationen. STRREPLACE und STRREPLACEALL laufen im Speicher. Response-Body-Umschreibung ist kostspieliger, da sie Body-Pufferung und Regex-Verarbeitung erfordern kann, daher sollte sie nur dort eingesetzt werden, wo Pfad-Remap-Szenarien es wirklich erfordern.
Wenn bei der Umschreibung ein FX-Parse-Fehler, eine fehlende Variable oder eine Regex-Nichtübereinstimmung auftritt, kann die Anfrage über einen sicheren Fallback durch den normalen Fluss fortgesetzt werden — sie wird nicht abgebrochen. Der Fehler wird in das Audit-Log geschrieben, damit der Operator das Konfigurationsproblem später untersuchen kann. Dieses Verhalten schützt den Produktionszugang vor Unterbrechungen durch eine falsch konfigurierte Regel.
Das empfohlene Muster für transparentes Pfad-Remap besteht aus zwei Teilen: Auf der Anfragen-Seite wird der externe Pfad in den internen Pfad umgewandelt; auf der Antwort-Seite werden interne Pfade im Response-Body zurück in externe Pfade geschrieben. Diese beiden Regeln laufen als aufeinander abgestimmtes Paar unter demselben vService. Dieses Muster wird zur Standardstruktur für API-Gateway-Szenarien, B2B-Partnerintegrationen und Monolith-zu-Microservice-Migrationsprojekte.
Bestehende Clients verwenden weiterhin `/api/v1/...`-Endpoints, während TR7 die Anfrage intern in die `/api/v3/...`-Struktur umwandelt. Die v3-Links im Response-Body werden über modifyResponse zurück in das v1-Format geschrieben. Das moderne Backend wird aktiviert, ohne jegliche Client-Code-Änderungen.
Ein Partner kann das `/services/payments/...`-URL-Schema jahrelang verwendet haben, während das interne Team zu `/v2/payment-api/...` gewechselt hat. Eine partnerspezifische set_path-Regel, die auf den Host-Header des Partners abgegrenzt ist, übernimmt die Übersetzung. Der Partner arbeitet weiterhin mit der alten URL; die neue Service-Architektur läuft intern.
Ein Legacy-Monolith bedient `/app/orders`, `/app/users` und `/app/inventory`-Pfade, die jeweils in einen separaten Backend-Service verschoben werden. TR7 wendet präfixbasiertes Routing und Pfad-Remap an, ohne die Aufteilung für Clients sichtbar zu machen. Benutzer behalten dasselbe URL-Schema, während Services im Hintergrund getrennt werden.
Ein Angreifer kann prozentcodierte Pfade, Dot-Segment-Traversals oder Schrägstrichverwirrung versuchen, um den WAAP-Signaturabgleich zu umgehen. normalize_uri bringt den Pfad in kanonische Form, und nachfolgende WAAP-Kontrollen operieren auf diesem bereinigten Wert. URL-Varianten, die unterschiedlich geschrieben sind, aber dieselbe Ressource anvisieren, werden konsistenter bewertet.
API-Versionierung, B2B-Partnerkompatibilität und transparentes Backend-Pfad-Remap — lassen Sie uns ein Live-Setup auf Ihren eigenen Services durchgehen.