Rails%203%20In%20Action

Mounting a Rack application with Rails
Now remember, to make requests to the
Heartbeat::Application class you must
prefix them with /test; otherwise they’ll be
served by Heartbeat::TestApplication.
Keeping that in mind, let’s make a request
to http://localhost:9292/test/200. You’ll see
something unusual: the path displayed on Figure 18.2 Success or FAILURE?!
the page isn’t /test/200 as you may expect,
but rather it’s /200. The env["PATH_INFO"]key doesn’t need to contain the path
where your application is mounted, as that’s not important for routing requests within
the application itself.
If you make a request to another path not beginning with the /test prefix (such as
http://localhost:9292/foo/bar), you’ll see the two buttons in forms provided by the
Heartbeat::TestApplication, as shown in figure 18.2.
When you click the Success! button, you’ll send a request to the/test/200 path,
which will be served by the Heartbeat::Application class and will respond with a
body that says /200 == Success!. When you click the back button in your browser
and click the Failure! button, you’ll see the /500 == Failure!.
This is the basic foundation for Rack applications and a lightweight demonstration
of how routing in Rack applications works. When you began, you were able to write
run Heartbeat::Application to run a single class as your Rack application, but as it’s
grown more complex you’ve split different pieces of the functionality out into different
classes. To combine these classes into one super-application you used the
Rack::Builder.app method.
Now you should have a basic understanding of how you can build Rack applications
to have a lightweight way of creating dynamic responses. So how does all of this
apply to Rails? Well, in Rails you’re able to mount a Rack application so that it can
serve requests on a path (like you did with Rack::Builder), rather than having the
request go through the entire Rails stack.
18.3 Mounting a Rack application with Rails
Sometimes, you’ll want to serve requests in a lightning-fast fashion. Rails is great for
serving super-dynamic requests quickly, but occasionally you’ll want to forego the
heaviness of the Rails controller stack and have a piece of code that receives a request
and quickly responds.
Previously, your Rack application had done just that. However, when you mount
your Rack application inside of a Rails application, you’re able to use the classes (that
is, models) from within the Rails application. With these models, you can do any number
of things. For example, you can build a re-implementation of your tickets API,
which will allow you to see an alternate way to craft the API you created in chapter 13.
So let’s do this.
525