モダンなアプリケーションアーキテクチャは常に進化しています。API v1として生まれたエンドポイントがv3に到達し、マイクロサービス分割後にモノリス背後のパス構造が変わり、B2Bパートナーが異なるURLスキームに慣れており、またはモダナイゼーションプロジェクトが新しいパスレイアウトを課します。変更のたびにクライアントまたはバックエンドをゼロから再設定する必要があれば、プロジェクトは技術的なタスクではなく長期的な調整作業になります。
従来のアプローチは2つの悪い選択肢を提供します。1つ目はバックエンドに新しいパスサポートを追加することです — 古いエンドポイントを維持しながら新しいエンドポイントも書くことはコードの複雑性とテスト負荷を倍増させます。2つ目はクライアントやパートナーに新しいパスへの移行を強いることです — これは社会的・運用上の摩擦を生み、B2B契約の再交渉が必要なことが多く、モバイルアプリのアップデートを待ち、移行スケジュールが延びます。
正しいモデルは、リクエスト-レスポンスフローに制御された書き換えレイヤーを導入することです。このレイヤーはクライアントが送るパスをバックエンドが理解するパスに変換し、必要に応じてレスポンスボディの内部パスをクライアントが期待する外部パスに書き戻します。バックエンドは内部でモダナイズされ、クライアントやパートナーは既知のURLスキームで動作し続けます。
このレイヤーが効果的であるためには3つの条件が必要です。第1は柔軟な検索置換ロジック：固定パス、プレフィックス置換、クエリ保持、FXベースの文字列変換をすべてサポートする必要があります。第2は条件付き適用：ルールはすべてのリクエストにではなく、正しいHost、メソッド、IP、クッキー、ヘッダー、またはFX条件が一致した場合にのみ適用される必要があります。第3はレスポンスボディとの双方向マッピング：そうでなければバックエンドが返す内部リンクはクライアント側で壊れたURLになります。
TR7 URLとパスの書き換えはこのモデルを提供します：set_path、set_pathq、normalize_uriアクション；FX STRREPLACE / STRREPLACEALLパターン；FX/ACL条件付き適用；modifyResponseによる双方向パスマッピングが、透過バックエンドパスリマップアーキテクチャの基盤を形成します。
TR7のURL書き換えレイヤーは、単純なパス置換をはるかに超えて、アプリケーションアーキテクチャレイヤー間に制御されたブリッジを構築します。
`/api/v1/users/123`へのリクエストをバックエンドが期待する`/internal/v3/users/123`パスに変換できます。set_pathはパスのみを変更し、set_pathqはパスとクエリ文字列を一緒に書き換えます。クライアントは既存のURLを送り続け、バックエンドは新しいアーキテクチャで動作します。
固定パス置換では不十分な場合、FX式言語が引き継ぎます。STRREPLACEとSTRREPLACEALLはパス内の特定セグメント（プレフィックス、サフィックス、またはパス中間部）を変換します。オペレーターは変数、検索置換フィールド、条件を同一のルールモデル内で組み合わせられます。
すべての書き換えルールにFX/ACL条件でスコープを設定できます。ルールは一致するHost、メソッド、ソースIP、クッキー、ヘッダー、またはFX変数値にのみ適用されます。同一vService配下で異なる条件を持つ異なるパス変換を並行して実行できます。
リクエストパスの変更だけでは不十分なことが多く、バックエンドがレスポンスボディに内部パスを返すことがあります。modifyResponseを使用することで、HTMLリンク、JSON hrefフィールド、または内部パスを含むテキストが外部パス形式に書き戻されます。クライアントの視点から完全に透過的なバックエンドパスリマップアーキテクチャが実現します。
URLパス書き換えは単一のアクションではなく、移行、互換性、双方向パス隠蔽パターンのための基盤となる構成要素です。
set_pathはリクエストのパス部分を新しいパス値で置き換えます。新しい値は静的に書くか、`%HOST`、`%PATH`、`%METHOD`、`%SRCIP`などのスマートコンテンツ変数で動的にできます。set_path使用時クエリ文字列は保持されません；クエリデータを保持する必要がある場合はset_pathqが推奨されます。このアクションは古い外部URL構造を新しい内部サービスレイアウトにマッピングするために使用されます。
set_pathqはパスとクエリ文字列を単一の書き換えアクションで管理します。オペレーターは新しいパスに既存の`%QUERY`値を含めてクライアントが送ったパラメータを保持できます。新しいパラメータを追加することも可能です — 例えば`/api/v1/users?id=42`を`/internal/v3/users?id=42&version=v3-from-v1`に変換できます。これはAPIバージョニングとパートナー互換性のための実用的な移行メカニズムです。
normalize_uriはパスとURIコンポーネントを標準形式に正規化します。オプションには、複数スラッシュのマージ、ドットセグメントの除去、`../`トラバーサルの解決、RFC 3986に従った安全文字のデコード、パーセントエンコードシーケンスの大文字化、フラグメントの処理、クエリパラメータのアルファベット順ソートが含まれます。この正規化はキャッシュキーの一貫性、監査の可読性、セキュリティバイパス試みへの耐性に重要です。WAAPおよびその他のセキュリティコントロールが同一の正規パスで決定を下すことにも役立ちます。
STRREPLACEは最初の一致を置換し、STRREPLACEALLはすべての一致を置換します。オペレーターは`%PATH.STRREPLACE("/old/", "/new/")`のような式を書いてパス内の特定セグメントを変換できます。このアプローチはプレフィックス置換、パス中間セグメントの置換、レガシーURLセグメントを新しいサービスレイアウトに移動するために使用されます。UIヘルパーフィールドにより検索置換値の入力がより制御しやすくなります。
すべてのパス書き換えルールを条件付きで実行できます。条件はHostヘッダーの一致、HTTPメソッドの制約、ソースIPレンジチェック、クッキーまたはヘッダー値の比較、またはFXエンジンが生成するtrueまたはfalseの式を使用できます。同一のvService配下で、パートナー固有、テナント固有、またはメソッド固有のパス変換が異なる条件で共存できます。一致しないリクエストは影響を受けずに通常のフローで続行されます。
set_pathまたはset_pathqがリクエストパスを内部パスに変換すると、バックエンドはレスポンスボディに内部パスを返すことがあります。modifyResponseのreplaceモードがその内部パスを外部形式に書き戻します。例えば：クライアントが`/api/v1/orders`をリクエストし、バックエンドは`/internal/orders`で動作し、レスポンスJSONの`"href":"/internal/users/42"`が`"href":"/api/v1/users/42"`として返されます。クライアントはバックエンドの実際のURL構造を見ることなく動作します。
modifyResponseはパスリマップだけに限定されず、レスポンスボディに対する異なる変換をサポートします。replaceモードはregexまたはプレーンテキストパターンをマッチして置換し、パスリマップの主要ツールです。htmlTagモードはHTMLタグに制御されたコンテンツを注入します。maskモードは機密データを隠蔽します。URLとパスの書き換えコンテキストでは、この機能は特に双方向パスマッピングのために位置づけられます。
パス書き換えはリクエストフェーズで、後段のセキュリティコントロールがリクエストを評価する前に適用されます。つまり、Virtual Patching、WAAPシグネチャマッチング、レート制限キー、トラフィックルールはすべて書き換えられたパスで動作します。正規化または再配置されたパスは後続のすべての決定レイヤーの共通入力になります。外部URLと内部サービスパスのギャップはポリシーの不一致を生じさせなくなります。
パス変換は運用上観察可能でなければなりません。TR7は元のリクエストパスと書き換えられたパス値を監査ログストリームに記録できます。SIEMサイドで「クライアントはどのパスをリクエストしたか、システムはどのパスをバックエンドに送ったか」という問いに答えられるようになります。この可視性は移行プロジェクトとセキュリティレビューで重要です。
同一のvService配下で複数のパスルールを順番に実行できます。最初のルールがURIを正規化し、2番目がプレフィックス置換を行い、3番目が特定の条件下でクエリ文字列を充実させたりサフィックスを追加したりします。各ルールは前のルールの出力で動作します。このモデルにより、単一の大きくてリスクのあるルールではなく、読みやすく、テスト可能で、インクリメンタルな変換チェーンが実現します。
URLパス書き換えは、スマートコンテンツ変数、FX統合、条件言語、パフォーマンス特性、エラー動作、レスポンス書き換えパターンと共に運用されます。
新しいパス定義には`%PATH`、`%QUERY`、`%HOST`、`%METHOD`、`%SRCIP`、`%PORT`およびカスタム変数を使用できます。これらの変数はset_pathとset_pathqアクションの値フィールドで組み合わせて動的パスを生成します。FX関数はこれらの変数に適用できます。
URLパス書き換えはTR7 FX式エンジンのコンシューマーの1つです。オペレーターはパス変換のために別の言語を習得する必要はなく、同じ式ロジック内でSTRREPLACE、STRREPLACEALLおよびその他のFX関数を使用します。この共有モデルにより、トラフィックルール、ログテンプレート、条件定義にわたって一貫した管理アプローチが提供されます。
FX/ACL条件が書き換えスコープを絞り込みます。`%HOST == "partner.example.com"`、`%METHOD in ["POST","PUT"]`、`%SRCIP in MAP_IP("partner_ips")`、`%HEADER("X-Tenant") == "tenant-a"`などの式がすべて有効です。複数の条件はAND/ORロジックで組み合わせられます。
パス書き換えはリクエストごとのオーバーヘッドが低く、文字列ベースの変換には追加のソケットやファイル読み取り操作は不要です。STRREPLACEとSTRREPLACEALLはメモリ上で実行されます。レスポンスボディ書き換えはボディバッファリングとregex処理が必要なためより高コストです。パスリマップシナリオが真に必要な場合にのみ使用してください。
書き換え中にFXパースエラー、変数欠落、regexミスマッチが発生した場合、リクエストは安全なフォールバックを通じて通常のフローを続行できます — ドロップされません。エラーは監査ログに書き込まれ、オペレーターは後で設定の問題を調査できます。この動作により設定ミスのあるルールによって本番アクセスが中断されることを防ぎます。
透過パスリマップの推奨パターンには2つの部分があります：リクエスト側で外部パスを内部パスに変換し、レスポンス側でレスポンスボディの内部パスを外部パスに書き戻します。これらの2つのルールは同一のvService配下で一致したペアとして動作します。このパターンはAPIゲートウェイシナリオ、B2Bパートナー統合、モノリスからマイクロサービスへの移行プロジェクトの標準構造になります。
既存のクライアントは`/api/v1/...`エンドポイントを使い続け、TR7はリクエストを内部で`/api/v3/...`構造に変換します。レスポンスボディのv3リンクはmodifyResponseによってv1形式に書き戻されます。クライアントコードを変更することなくモダンなバックエンドが有効化されます。
パートナーが長年`/services/payments/...`というURLスキームを使用している一方、内部チームが`/v2/payment-api/...`に移行している場合があります。パートナーのHostヘッダーにスコープされたパートナー固有のset_pathルールが変換を処理します。パートナーは古いURLで動作し続け、新しいサービスアーキテクチャが内部で動作します。
レガシーモノリスが`/app/orders`、`/app/users`、`/app/inventory`パスを提供し、それぞれが別のバックエンドサービスに移動されています。TR7はプレフィックスベースのルーティングとパスリマップを適用し、クライアントに分割を公開しません。ユーザーは同じURLスキームを使い続け、バックグラウンドでサービスが分離されます。
攻撃者はパーセントエンコードされたパス、ドットセグメントトラバーサル、またはスラッシュの混乱を使ってWAAPシグネチャマッチングを回避しようとする場合があります。normalize_uriはパスを正規形式にし、後続のWAAPコントロールはこのクリーンな値で動作します。異なる書き方でも同じリソースをターゲットにするURLバリアントがより一貫して評価されます。
APIバージョニング、B2Bパートナー互換性、透過バックエンドパスリマップ — お客様自身のサービスでのライブセットアップをご案内します。