The ResponderMixin adds methods that help you manage what formats your controllers have available, determine what format(s) the client requested and is capable of handling, and perform content negotiation to pick the proper content format to deliver.

If you hear someone say "Use provides" they’re talking about the Responder. If you hear someone ask "What happened to respond_to?" it was replaced by provides and the other Responder methods.

A simple example

The best way to understand how all of these pieces fit together is with an example. Here’s a simple web-service ready resource that provides a list of all the widgets we know about. The widget list is available in 3 formats: :html (the default), plus :xml and :text.

class Widgets < Application
  provides :html   # This is the default, but you can
                   # be explicit if you like.
  provides :xml, :text

  def index
    @widgets = Widget.fetch
    render @widgets
  end
end

Let’s look at some example requests for this list of widgets. We’ll assume they’re all GET requests, but that’s only to make the examples easier; this works for the full set of RESTful methods.

1. The simplest case, /widgets.html Since the request includes a specific format (.html) we know what format to return. Since :html is in our list of provided formats, that’s what we’ll return. render will look for an index.html.erb (or another template format like index.html.mab; see the documentation on Template engines)
2. Almost as simple, /widgets.xml This is very similar. They want :xml, we have :xml, so that’s what they get. If render doesn’t find an index.xml.builder or similar template, it will call to_xml on @widgets. This may or may not do something useful, but you can see how it works.
3. A browser request for /widgets This time the URL doesn’t say what format is being requested, so we’ll look to the HTTP Accept: header. If it’s ’*/*’ (anything), we’ll use the first format on our list, :html by default.

   If it parses to a list of accepted formats, we’ll look through them, in order, until we find one we have available. If we find one, we’ll use that. Otherwise, we can’t fulfill the request: they asked for a format we don’t have. So we raise 406: Not Acceptable.

A more complex example

Sometimes you don’t have the same code to handle each available format. Sometimes you need to load different data to serve /widgets.xml versus /widgets.txt. In that case, you can use content_type to determine what format will be delivered.

class Widgets < Application
  def action1
    if content_type == :text
      Widget.load_text_formatted(params[:id])
    else
      render
    end
  end

  def action2
    case content_type
    when :html
      handle_html()
    when :xml
      handle_xml()
    when :text
      handle_text()
    else
      render
    end
  end
end

You can do any standard Ruby flow control using content_type. If you don’t call it yourself, it will be called (triggering content negotiation) by render.

Once content_type has been called, the output format is frozen, and none of the provides methods can be used.