モダンなAPIトラフィックでは、実際の決定データはヘッダーではなくボディにあります。
従来のレイヤー7トラフィック管理は通常、URL、メソッド、ヘッダー、ソースアドレスで決定します。そのモデルはクラシックなWebアプリケーションには十分なことが多いですが、モダンなAPIアーキテクチャでは重要な区別が通常リクエストボディ内のフィールドにあります。テナントID、ユーザーロール、トランザクションタイプ、サービス名、またはファイルアップロードのメタデータはヘッダーにはなく、JSON、XML、フォーム、マルチパートのペイロードにあります。
その可視性なしには、オペレーターは悪い選択肢に追い込まれます。トラフィック管理の前に追加のAPIゲートウェイを配置するか（新たなホップ、ライセンス、運用負担が増える）、決定値をヘッダーに持ち上げるためにアプリケーション自体を変更するかです。レガシーおよびビジネスクリティカルなバックエンドにとって、その変更はしばしば実行不可能です。
ボディ検査をセキュリティのみに限定しても問題は解決しません。WAAPがコンテンツを読めてもルーティングエンジンが同じ値を使用できなければ、セキュリティポリシーとトラフィックポリシーが二つの別々の世界になります。その結果、ロジックの重複、一貫性のないルール、エラーのリスク増大が生じます。
正しいモデルは、ボディパーサー機能をルール言語のネイティブな部分にすることです。JSONPath、XPath、フォームパラメータ、JWTクレーム、正規表現、マップ/リストチェックが同じ式ツリーに共存し、単一の式がトラフィックアクションとWAAPスコアの両方を制御すべきです。
TR7コンテンツ認識ルールはこのギャップを埋めます：ボディ内のフィールドは単なる検査データではなく、決定を直接制御するシグナルになります。
アプローチ
TR7はコンテンツ認識を別のアドオンとしてではなく、トラフィックとセキュリティのルール言語のネイティブな部分として扱います。
ボディパーサー関数がFX式言語に直接組み込まれている
JSONQUERY、XMLQUERY、XMLPATHEXISTS、PARAM、JWTHEADER、JWTPAYLOADはルール言語の一級関数です。オペレーターはカスタムコードを書くことなくボディコンテンツを条件に変換し、それらの条件を直接トラフィックまたはセキュリティアクションに結びつけます。
JSON、XML、マルチパートパーサーがランタイム内で実行
JSON、XML、マルチパートのペイロードはランタイムで解析され、読み取り可能な値としてルールエンジンに提供されます。オペレーターはリクエストのすべてのバイトに対して粗いregexを実行するのではなく、意味のあるフィールドで決定します。
同じDSLがトラフィック管理とWAAPスコアリングを制御
TR7では、ボディフィールドに対して書かれた式がルーティング、ヘッダー操作、WAAPシグネチャスコアリングのいずれも制御できます。この共有モデルにより、トラフィックルールとセキュリティルール間のロジックの重複が削減されます。
ADCとWAAPモードは異なる整合性ルールに従う
ADCモードではボディを読み取り、適切なシナリオではレスポンス側で書き換えることができます。WAAPモードではボディは決して変更されません — 読み取られ、スコアリングされ、ポリシー閾値を超えるとブロックされます。
機能
コンテンツ認識ルールは構造化されたペイロードデータを読み取り可能な条件と強制可能なアクションに変換します。
JSONPathクエリがAPIボディフィールドに直接ルールを記述
JSONQUERY関数は標準JSONPathセマンティクスを使用してJSONボディフィールドを評価します。オペレーターは`$.user.role`、`$.items[0].sku`、`$.tenant_id`などの値を条件として使用し、vServiceルーティング、ヘッダー操作、WAAPスコアリングに結びつけられます。APIトラフィックはエンドポイントだけでなく、リクエストの実際のビジネス的意味によって制御されます。
XML XPathチェックがSOAPとエンタープライズサービストラフィックを透明化
XMLQUERY、XMLPATHTYPE、XMLPATHEXISTSはXMLボディに対してXPathクエリを実行します。SOAPエンベロープ内のサービス名、アクションノード、オペレーションフィールドがルーティングとセキュリティの決定を制御できます。これはレガシーバックエンドを変更せずにサービスレベルのディスパッチとポリシーを適用するのに特に価値があります。XMLペイロードはルールエンジン内の構造化データになり、脆弱な正規表現への依存が減ります。
ルールの条件としてのFIXメッセージ種別とMQTTトピック
ルールはHTTPで終わる必要はありません。FIXのメッセージ種別とタグ、MQTTのトピックとパケット構造を、同じルールビルダーの条件として使えます。不正な注文メッセージや想定外のトピックは、マッチングエンジンやブローカーに届く前に、デリバリー層で捕まります。取引系とIoTのトラフィックは通常、不透明なTCPとして運ばれ、あとは祈るだけです。ここでは読まれます。そして読むためのルールは、チームがすでに書いているルールとまったく同じ形をしています。
フォームとマルチパートフィールドがテナント、ファイル、トランザクション決定を結びつける
PARAM関数はクエリ文字列、フォームエンコードされたボディ、フォームフィールドをルール条件に変換します。マルチパートパーサーはファイルアップロードのメタデータ（フィールド名、コンテンツタイプ、サイズ）をポリシーに提供します。このパターンはSaaSポータル、ドキュメントアップロードフロー、ユーザー固有のトランザクションロジックに役立ちます。フォームが持つビジネスコンテキストに基づいてトラフィックをルーティングまたはブロックできます。
JWTヘッダーとペイロード値が単一関数でクエリ可能
JWTHEADERとJWTPAYLOADはトークンのヘッダーとペイロードフィールドをJSONPathクエリ可能な値として提供します。ユーザーロール、テナント、認可レベル、カスタムクレームがトラフィックとセキュリティの決定への入力になります。必要なクレームをエッジで強制し、クレームが欠落したリクエストを失敗させ、ロールベースのトラフィックを専用のバックエンドグループに誘導できます — アプリケーションコードにアクセスロジックを埋め込まずに済みます。
マップとリストのルックアップが大規模データセットにルールを拡張
MAP_STR、MAP_REG、MAP_SUB、MAP_IP、MAP_BEG、MAP_ENDは大量の値セットに対する高速ルックアップを提供します。LIST_STR、LIST_REG、LIST_SUB、LIST_IP、LIST_BEG、LIST_ENDはリストベースのチェックに同じモデルを提供します。テナントリスト、許可サービス名、IPレンジ、パターングループを個別の条件としてではなく中央で管理でき、大規模なルールセットが維持しやすくなります。
ボディサイズ、深さ、フィールド数の制限がパース開始前に保護
BODY_SIZE、JSON_DEPTH、XML_DEPTH、JSON_KEY_COUNT、XML_NODE_COUNTはパーサーが動作する前に保護的な制限を定義します。サイズが大きすぎる、深くネストされた、または膨張したペイロードはバックエンドに到達する前に拒否されます。JSON_DEPTHのデフォルトは32でポリシーレベルで調整可能です。同じ制御がリソース消費とパーサーレベルの悪用の両方を管理します。
Allowed ArgsとMust Argsがポジティブセキュリティモデルを構築
JSON_MUST_ARGS、JSON_ALLOWED_ARGS、FORM_MUST_ARGS、FORM_ALLOWED_ARGSは期待されるフィールドの存在と予期しないフィールドの不在を検証します。悪いパターンを検索するだけでなく、受け入れ可能なリクエストの形状を宣言するモデルです。必要なフィールドの欠落や予期しないパラメータをポリシーごとに拒否できます。このコントラクト認識アプローチは重要なトランザクションエンドポイントで特に価値があります。
レスポンスボディの書き換えがADCモードでのマスキングと変換を可能に
ADCモードでは、modifyResponseアクションがレスポンスボディに正規表現ベースの置換を適用します。個人データのマスキング、リンクの書き換え、外部利用者向けの内部アドレスの適応に使用されます。WAAPモードではボディは決して変更されません — 読み取りとスコアリングのみです。この分離により、同一プラットフォームでトラフィックの柔軟性とセキュリティの整合性が両立します。
運用の深み
コンテンツ認識はルール構文だけではなく、バッファ管理、パースキャッシング、監査の可視性、エッジケースの動作もカバーします。
ボディバッファ管理
ボディコンテンツはパース前にバッファリングされ、関連するJSON、XML、またはマルチパートパーサーがそのバッファで実行されます。デフォルトのボディバッファは16 KBで、より大きなJSONまたはXMLペイロード用にシステムパラメータを引き上げることができます。制限を超えると、リクエストは413で拒否され、バックエンドは過大なペイロードを受け取りません。
パース結果のキャッシング
同一リクエスト内で読み取られたJSONPathとXPathの結果はトランザクションスコープの変数スペースにキャッシュされます。あるルールがボディフィールドを読み取ると、後続のルールは同じフィールドでパーサーを再実行しません。これにより、長いルールチェーンにおけるレイテンシと処理コストが削減されます。
WAAPの整合性モデル
WAAPモードではボディは読み取られますが決して変更されません。コンテンツはシグネチャ、スコアリング、閾値ロジックに供給されます；閾値を超えるとリクエストはブロックされます。セキュリティ層はリクエストの整合性をエンドツーエンドで保持しながらコンテンツ認識シグナルに基づいて動作できます。
チャンクリクエストの動作
チャンクされたPOSTリクエストのパースはチャンク再組み立て完了後に開始されるため、ボディフィールドは完全で一貫したペイロードとして評価されます。チャンクトラフィックは若干の追加レイテンシが発生する場合がありますが、バックエンドは部分的で制御されていないペイロードストリームから保護されます。
GraphQLの可視性
GraphQLは現在JSONPathを通じて処理されています：ボディ内のオペレーション名やフィールドリストなどのフィールドをルール条件に使用できます。これにより、ミューテーションとクエリの分割などの実用的なエッジ決定が可能になります。ディープスキーマ検証はこの機能のスコープ外です。
監査とSIEMトレイル
どのルールがどのボディフィールドを読み取ったかが監査ログに記録されます。運用チームは特定のリクエストがなぜルーティング、拒否、またはスコアリングされたかをSIEMでトレースできます。このトレーサビリティにより、コンテンツ認識ルールがブラックボックスのように動作するのを防ぎます。
利用シナリオ
JSON内のテナント値でルーティング
SaaSチームはJSONボディ内のtenant_idフィールドに基づいて別々のバックエンドプールにトラフィックを振り分けられます。テナントの分離はアプリケーションコードを変更せずに実現でき、トラフィックポリシーはエッジで管理されます。
SOAPアクションによるエンタープライズサービスのディスパッチ
銀行や政府のシステムでは、XMLエンベロープ内のアクションノードが異なるサービスグループへのディスパッチを制御できます。レガシーサービスコントラクトを維持しながら、トラフィック決定がコンテンツ認識になります。
GraphQLトラフィックをオペレーションタイプで分割
エンジニアリングチームはoperationNameフィールドに基づいてクエリとミューテーションを別々のソースに誘導できます。読み取り重視と書き込み重視のオペレーションが専用のバックエンドグループに配置されます。
JWTクレームに基づくアクセス決定の強制
重要なアプリケーションでは、JWTペイロード内のロールとテナントクレームをエッジで強制できます。必要なクレームが欠落したリクエストはバックエンドに到達せず、有効なクレームを持つリクエストは適切なトラフィックポリシーの下に配置されます。
よくある質問
ボディパーサーはどのコンテンツタイプをサポートしますか？
同じルールがADCトラフィックとWAAPポリシーの両方を制御できますか？
ADCモードとWAAPモードの整合性の違いは何ですか？
JWT内容はルール式でどのように使用されますか？
非常に大きいまたは深くネストされたボディをシステムはどのように処理しますか？
複数のルールが同じボディフィールドを読み取る場合、パースは複数回実行されますか？
APIの決定をヘッダーではなくボディで行う
JSON、XML、マルチパート、JWTフィールドにわたるコンテンツ認識ルーティングとセキュリティ。お客様自身のサービスでのライブセットアップをご案内します。