rails-api: ActionController::ParamsWrapper is not on by default

@johnbendi, Sorry, I had put more detail into the other ticket I wrote.

Rails autogenerates this:

#config/initializers/wrap_parameters.rb
ActiveSupport.on_load(:action_controller) do
  wrap_parameters :format => [:json]
end

You can fix it by changing to this:

ActiveSupport.on_load(:action_controller) do
  wrap_parameters :format => [:json] if respond_to?(:wrap_parameters)
end

Using an rails-api generated (v0.4.0) the generated code in config/initializers/wrap_parameters.rb has the respond_to in there as expected but… it does not work. Had to go with @cimm fix.

If i got the discussion right it shouldn`t be the case. Am i missing something?

We could say the same thing for everything else that rails-api does by default, like disabling session/cookies, etc. Why do we do that and don’t stick with Rails defaults? Because we try to remove a bit of clutter for api applications, that’s the main goal - otherwise we could just stick with Rails.

ParamsWrapper could be considered a module most people don’t even realize that exists in Rails itself, even thought they might be using json everywhere. That’s why for me it makes sense to have it disabled by default in rails-api, to remove another “mostly not used” module, even though it’s useful in some particular scenarios.

I believe that people using rails-api have a good understanding of what it does, and with that in mind, they should be capable of knowing what’s ParamsWrapper and whether it can be useful for them - or not at all. And since it’s a matter of adding an include in the application, I like to believe it is fine enough.

Anyway, that are just my thoughts, if it’s agreed that it’d be better to have it enabled, I’m fine as well 😃.

@jerodsanto so it’s working properly for you, right?

Considering it’s actually disabled by default, and Rails generates that file, we probably have 2 options (that I can think of):

• Add ParamsWrapper by default;
• Override that file as well, and comment out / remove the stuff that says it’s enabled by default.

Although I agree with @jerodsanto that sometimes it might be useful to have such a functionality, there are others, specially when you’re exposing your api to the outer world publicly, that it doesn’t make much sense I think. When you are building an application that serves as an api for other or for a javascript based front-end, i.e. using backbone.js, it may make all difference, but other than that, I think we’d be fine by letting it disabled by default and explaining how to enable it if necessary.