すべてのルートに無差別に適用される横断的な関心事を対象としています。フィルターの一般的なユースケースは、例えば以下のようなものです。認証や認可、キャッシュなど、特定のルートに対する関心事を対象としています。フィルターをすべてのルートに適用したいのでなければ、代わりにアクション合成の使用を検討してみてください。アクション合成はフィルターよりも遙かに強力です。定型的なコードを最小限にするために、ルート毎に独自の定義済みアクション群を構成する、アクションビルダーを作成できることも忘れないでください。}}ここで何が起きているのか理解してみましょう。メソッドのシグネチャです。引数は、フィルターチェーンにおける次のアクションを表現しています。これを実行すると、次に呼ばれるべきアクションが起動します。ほとんどの場合において、後続の処理のいくつかのタイミングで次のアクションを実行したくなることでしょう。何らかの理由により、リクエストをブロックしたいのであれば、次のアクションを実行しないと決断するのも良いかもしれません。引数は、このリクエストの実際のヘッダーです。コードの次の部分は、リクエストのログを出力する関数です。記録するヘッダを記録して返します。最後に、次のアクションが実行され、このアクションが返す結果のパターンマッチが行われます。関数が実行される必要がありますが、その実行方法はそれぞれ少しだけ異なっています。場合、結果はまだ利用できません。メソッドに渡されます。なんらかのスコープ内においてのみ使用することができます。LoggingFilter(action)}§フィルターはどこに合う?フィルターは、アクションがルーターによって見つけられた後に、そのアクションをラップします。これは、フィルターを使ってルーターに影響を与えるパスやメソッド、そしてクエリパラメーターを変換できないことを意味します。フィルターから別のアクションを実行することで、リクエストをそのアクションに移動させてしまうこともできますが、これをするとフィルターチェーンの残りをバイパスしてしまうことに気を付けてください。配置するのが、より良いやり方でしょう。マップによってリクエストからルーティング情報にアクセスすることができます。アクションメソッドに対する実行時間をログに出力したいとします。独自のアクションを返す場合は、これらのパラメーターは利用できない場合があります。他のアクションでラップすることができます。内においてこれをラップすることで、様々な変換を行うことができます。