Respond_to in Ruby)

Through the previous lecture, we have some knowledge about the basic framework of rest on rails, but how does it return different types of resource representations Based on the client request type? This is what we want to talk about. The secret lies in respond_to.

First, let's take a look at the airports controller generated in the previous section.Code:

Class airportscontroller <applicationcontroller
Def Index
@ Airports = airport. Find: All
Respond_to do | format |
Format.html # Do nothing, allow rails to render index. rhtml
Format. js # Do nothing, allow rails to render index. RJS
Format. xml {renderml => @ airports. to_xml}
End
End
End

Taking the index method as an example, the implementation of other methods is similar. The first line of code is easy to understand. It gets all airport information, but the following code is confusing, and this is the key to rest on rails, what is respond_to?

As we know, in the HTTP protocol, the client will include some meta-information in their HTTP header, which is organized by "field: value, the HTTP protocol predefines many standard fields. One of the fields is "Accept-type", which indicates the type of resource representation supported or understood by the client sending the request, if a value is not specified for this key, the server determines that the client can understand the standard HTML document. Of course, the client can specify any mime-compliant type value for this field, if the client sets this field to "Accept-type: text/XML", the server must return the XML Representation of the resource.

Therefore, respond_to is actually determined to return the type of resource representation to the client based on the accept-type field of the HTTP header. If respond_to is not used, our implementation may look like this:

Class airportscontroller <applicationcontroller

# Pretend that rails will call our index action,
# And will pass in the value of the accept-Type Header
Def index (client_format)
@ Airports = airport. Find: All

If client_format = "text/html"
# To do: render the default Template

Elsif client_format = "application/JavaScript"
# To do: return some Javascript

Elsif client_format = "application/XML" | client_format = "text/XML"
# To do: return some XML back the client

#... More elsif statements here for each MIME type you want to support
End
End
End

This is ugly, isn't it? But it is quite intuitive. I think the author of respond_to may have written the same thing at first, or the code was at least flashed in his mind, but he immediately gave up the code, because it is really too bad, so he reorganized the code, so there is respond_to.

Respond_to do | format |
Format.html # Do nothing, allow rails to render index. rhtml
Format. js # Do nothing, allow rails to render index. RJS
Format. xml {renderml => @ airports. to_xml}
End

However, the Code in the block still looks odd. In fact, if we understand the design idea of respond_to, this code seems to be taken for granted.

Respond_to is designed based on this idea. You don't need to know the type of client requests. You just need to tell rails that you are ready to support those types of requests, rails will automatically help you deal with the rest.

Therefore, we will tell rails that the default implementation is used for HTML and JS requests, while the implementation provided in the block is used for XML requests.

This is the end of the Guide and the length is limited. We can only introduce the basic concept of rest and its simple implementation in rails, there are more things to explore in the rest on Rails world.

I suggest you try to create a rails application, then try the scaffold_resource generator, read and understand the generated code, and then try to modify the view and controller. In fact, it's much simpler than you think, isn't it?