27.02.2013 Views

Rails%203%20In%20Action

Rails%203%20In%20Action

Rails%203%20In%20Action

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Building Rack applications<br />

call. When Rack receives a request to this application it will call the call method on<br />

the object passed to run, which will then generate and return a response back to the<br />

server. The object in this case is a lambda (or Proc) object, which automatically<br />

responds to call.<br />

When the call method is called on this lambda, it will respond with the threeelement<br />

array inside it, completely ignoring the env object that is passed through.<br />

Inside this array, you have the three elements Rack needs: the HTTP status, the headers<br />

for the response, and the body to return.<br />

To see your lib/heartbeat.ru in action, you can launch a Rack server by using the<br />

command you saw in the sidebar:<br />

rackup lib/heartbeat.ru<br />

This is now running a server on 9292 (the standard port for Rack) using the built-into-Ruby<br />

WEBrick HTTP server, as indicated by the server output you’ll see:<br />

[timestamp] INFO WEBrick 1.3.1<br />

...<br />

[timestamp] INFO WEBrick::HTTPServer#start: pid=... port=9292<br />

You can now go to your browser and open http://localhost:9292 to make a request to<br />

this application. You’ll get back “Hello World,” and that’s okay. You can also make a<br />

request to any path at the http://localhost:9292 application and it will respond in the<br />

same way, such as http://localhost:9292/status.<br />

What you’ve done here is write one of the simplest Rack applications possible. This<br />

application receives a response to any path using any method, and always responds<br />

with OK. This application will respond very quickly because it hasn’t loaded anything,<br />

but at the cost of being a one-trick pony.<br />

You can make this little application respond differently in a number of ways. The<br />

easiest (and most fun!) would be to program it to change its response depending on<br />

the path it’s given, like a Rails application does. For this, you’ll use the env object. First<br />

up, let’s see what this env object gives you by changing your script to do this:<br />

require 'yaml'<br />

run lambda { |env| [200,<br />

{'Content-Type' => 'text/plain'},<br />

["#{env.to_yaml}"]]<br />

}<br />

The to_yaml method provided by the yaml standard library file will transform your<br />

env object (spoilers: it’s a Hash) into a human-readable YAML output (like that found<br />

in config/database.yml in a Rails application).<br />

To make this new change apply, you can’t refresh the page like you would in a Rails<br />

application; you have to stop the server and start it again. You can press Ctrl+C to stop<br />

it, and rerun that command. This time when you go to your server, you’ll see output<br />

that looks like this:<br />

---<br />

GATEWAY_INTERFACE: CGI/1.1<br />

519

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!