Some discussion on respond_to, respond_with…
This was broken out into the responders gem for 4.2.
Here’s a couple discussions on this:
Any opinions if this responders gem should be included in new Rails projects?
Justin Weiss makes the case that you’ll get the wrong error message.
However, why not dry up the code even more by not worrying about having the wrong error message and capturing the ActionView::MissingTemplate level and mapping it a different error in production?
There is much any different if we use respond_to or respond_with in the default way, and Justin Weiss writes a great article that you mentioned earlier.
For me, the only benefit of using respond_with that includes in responders when we want our response to be consistence or by convention, so that we could DRY some codes in controllers. For example, we create ApiResponder, and then all create or update actions will generate response base on model’s state. It seems it’s the default behavior of respond_with, but sometimes we want to customize how the errors response generated when model saved fail [1].
[1] https://coderwall.com/p/opbyiw/display-activerecord-errors-as-i18n-keys-in-rails-json-api
I started with using respond_with, because one of my first Rails mentors advised to use it. Later, I encountered some issues with lack of flexibility in the return messages. Since then, I only use respond_to. In fact, I have respond_to in application_controller.rb. It works well for a RESTful Rails API.
In my controllers, I have something like render json: and I can respond with any JSON object, I like e.g. @user; { errors: @user.errorrs.full_messages }; user; { errors: params[:message] }; {}; etc. Only requirement is that it need to be a JSON object.
I hope this helps.
