APIkit ルーターは、提供された定義に対してリクエストを検証し、メッセージを拡充し (たとえば、メッセージにデフォルト値を追加する)、リクエストを特定のフローにルーティングする主要なメッセージ プロセッサです。
また、ユーザー要求のルーティング、検証、または処理中にエラーが発生した場合、ルーターはエラー メッセージを生成します。

パス
HTTP リスナーのパスは静的である可能性があり、その場合は完全一致、または機能プレースホルダーが必要になります。
プレースホルダーは、比較対象となる任意のものと一致するワイルドカード (*)、または任意のものと一致するだけでなく URI パラメーター マップ上の値をキャプチャするパラメーター ({param}) にすることができます。
api/v1 をベースパスとして確立する構成を使用して、3 つのリスナーの次の例パスを考えてみましょう。
アカウント/Mulesoft/メイン連絡先:
正確なパスリクエストのみ一致します http://awesome-company.com/api/v1/account/mulesoft/main-contact account/{accountId}/main-contact:
http://awesome-company.com/api/v1/account/salesforce など、同様に構造化されたすべてのパス リクエストに一致します。
/main-contact を実行し、salesforce を accountId の値として保存します。
アカウント/{アカウントID}/*:
main-contact とは異なるすべてのパス リクエストに一致します (例: http://awesome-company.com/api/v1/account)
/mulesoft/users にアクセスし、accountId の値として mulesoft を保存します。
Mule 参照ドキュメント: https://docs.mulesoft.com/http-connector/1.6/http-listener-ref#paths

属性は、HTTP リクエスト応答からの新しい属性に置き換えられます。
属性には、ペイロード/本文以外のすべてが含まれます。例：ヘッダー、クエリパラメータ、URIパラメータ。
したがって、アウトバウンド HTTP 要求が行われると、新しい属性がアウトバウンド HTTP 要求を渡す必要があり、古い属性は置き換えられます。
理解しやすいように以下の図を作成しました。
図の説明が自動的に生成されました

正解はプロセス レイヤーです。Mulesoft が API 主導の接続に推奨するアプローチに従って、すべてのオーケストレーションおよび変換ロジックはプロセス レイヤーにある必要があるためです。
API主導の接続性は、再利用可能で目的に応じたAPIを介してデータをアプリケーションに接続する体系的な方法です。これらのAPIは、システムからデータを解放したり、データをプロセスに組み込んだり、エクスペリエンスを提供したりといった特定の役割を果たすために開発されています。
API 主導の接続性を可能にする API とは何ですか?
API主導の接続性は、アセットを接続および公開するためのアプローチを提供します。このアプローチでは、ポイントツーポイントで接続するのではなく、すべてのアセットがマネージドAPI（最新のAPI）となり、制御を失うことなくセルフサービスで検出できるようになります。
API 主導の接続アプローチで使用される API は、次の 3 つのカテゴリに分類されます。
システムAPI - これらは通常、コアシステムにアクセスし、基盤となるシステムの複雑さや変更からユーザーを保護する手段を提供します。一度構築すれば、多くのユーザーは基盤となるシステムを学習することなくデータにアクセスでき、複数のプロジェクトでこれらのAPIを再利用できます。
プロセス API - これらの API は、単一のシステム内またはシステム間 (データ サイロを解体) でデータと対話してデータを形成し、データの元となるソース システムや、データが配信されるターゲット チャネルに依存せずにここで作成されます。
エクスペリエンスAPI - エクスペリエンスAPIは、各チャネルごとに個別のポイントツーポイントの統合を設定するのではなく、共通のデータソースからデータを再構成し、対象ユーザーが最も簡単に利用できるようにするための手段です。エクスペリエンスAPIは通常、APIファーストの設計原則に基づいて作成され、特定のユーザーエクスペリエンスを念頭に置いて設計されます。

オプション1はHTTPリスナーエンドポイントを構成するための正しい構文です