Newbie: Are filters the right place to modify the response data, based on request parameters?

My question is very simple: In an averagely complex web reques开发者_开发百科t, usually we have quite a lot of information in terms of request parameters. In many cases some of those parameters are such that the controller action should not ever even be interested in, such as for example referrer_id, (for analytics purposes) if the request came from clicking a link on a third-party website, or from an email newsletter.

Another example: On quora, if you enter the following url: http://www.quora.com/As-a-mobile-apps-developer-on-what-platform-should-I-choose-to-develop-and-why you will be led to the normal web page, however, if you enter the same url, but with the (snids=24082824) parameter at the end, you get the page content, plus some additional overlaying content (In this case, information about who edited the question last)

I think to it would be stupid to check for the existence and values of every single request parameter in the controller action. That would urn the action in an if-else if-else soup.

Filters seem a much better alternative to break and decouple all the varying elements of a request, right? Using filters, once could completely change the workflow in mere seconds, without breaking and messing with controller actions. Controller actions are there to grab a view based on the url pattern of the request, but it is a duty of the filters to modify the request/response, intercept, log, or even override controller actions, if there is some more parameter sugar in the request, right?

Just a small note, I wouldnt use filters to modify the request and response. It is possible given that those objects are available to the filters. Using filters to do small time things that would keep the actions clean, or enforce access controls specific to an application sounds nice. But if its about modifying the request and response then I would prefer a custom Rack middleware. After all every rails app is a rack app.

Yes filters is the right way to go.