Rails%203%20In%20Action

Brand-new engine
HTTP status code, then Rack moves on to the next one, going all the way through
each part of the stack, moving on to the next every time the current part returns a 404
until it hits the application. The application is the final stop of this request, and so
whatever it returns goes. In this case, the application returns a 200 (“OK”) request,
which is then passed back to the client through Rack.
If a non-404 response was ever returned from a middleware object, then the digging
would stop there, and the response would climb back to the surface.
In a Rails application, the routing is actually a piece of the middleware stack. As
the request goes through the chain, it eventually comes to the routes, which then
determine where the request should head. When routing requests to an application,
the sequence looks like figure 17.3.
In this example, Rack still receives the request and goes through the middleware
stack, with each middleware passing the buck until it comes up to the routes. This then
handles the request, routing the request to (usually) a controller, which then executes
the necessary code to get the job done and passes the result back up to the client.
An engine is served in much the same way; you mount it at a specific path in your
application’s config/routes.rb line with this line:
mount Forem::Engine, :at => "/forem"
Any request to the /forem path will not be passed to the application, but instead
passed to the engine. The engine then decides how to route that request and returns
a response exactly like an application. This process is shown in figure 17.4.
2. Goes through middleware
stack until...
1. Request comes in for
GET /projects
Middleware #1
Middleware #n
3. Routes receive request
Browser
Server
... Application Engine
Routes
7. Response goes out
6. Application responds
5. That route goes to
the application!
477
4. What route is it?
GET /projects Figure 17.3 Application route cycle