最新のRuby on Rails（この質問をした時点では4）では、認証メカニズムなどのリクエスト/レスポンスを変更するコードを実装するための推奨方法は何ですか？ Rack middlewareを提唱している多くのサイトとチュートリアルが表示されていますが、同じ機能が、Action Controller filter methodsで実現できるようです。有利な方法論の話に加えてRoR - ラックミドルウェアまたはアクティブコントローラのフィルタが優先されますか？
は、それぞれの長所と短所の比較を提供することができますか？私の最初の調査では、アクションコントローラーのフィルターメソッドは、より密接にRoRアプリケーションに統合されているため、特定のコントローラーのエンドポイントで特定のフィルターを実行することを回避できる一方、ミドルウェアはそのレベルの制御を持つことができないようです。このような詳細は素晴らしいでしょう。ありがとう！
ラックミドルウェアとActionCoフィルタは実際にはかなり異なっています。
ラックは、標準のRubyのWebサーバ・インタフェースです。これは、Rackアプリケーションまたは「ミドルウェア」を連鎖させて、特定の方法で要求/応答を変換するように動作するように設計されています。 Rack Middlewareを作成/使用する場合は、実際にRailsアプリに到達する前にリクエストを変換する機会があります。
ActionControllerフィルターRailsの中にあなたの即時のコントローラメソッドの前または後に実行フック前/後に、単純です。これらは、コントローラのメソッドの直前または直後に呼び出されますが、以降はの後にRailsスタック全体が呼び出されます。
したがって、Rack MiddlewareとActionControllerフィルタでは、アプリケーションコードの前にRack Middlewareが実行されているため、アプリケーションコードと同じスコープで実行されないため、例えば明示的に要求し、必要な初期化（データベース接続の確立など）を実行しない限り、アプリケーションモデルなどを使用することはできません。
あなたが唯一の特定のコントローラのメソッドの前に要求に何かをしたい場合：
あなたがここに私の頭の上から、親指のルールを探しているなら、私はあなたを言うだろうものですそのコントローラーのフィルターを使用してください。
アプリケーション内のすべてのコントローラメソッドの前にリクエストを処理したい場合や、アプリケーションに固有のものやアプリケーションコードに依存するものがある場合は、ApplicationControllerでフィルタを使用します。
リクエストで一般的な処理を行いたい場合は、アプリケーションコードにまったく関係なく、別のアプリケーションで再利用できるといいと思いますが、Rack Middlewareはよりよくフィット。
希望します。
私の知る限りは、アクションコントローラのフィルタを理解し、ラックミドルウェアは、その二つのものを除いて、ほとんど同じことをやっているよう：あなたはいくつかのパフォーマンスを得ることができるように、