Rails%203%20In%20Action

530 CHAPTER 18 Rack-based applications
By placing this mount call inside the namespaces, the Rack application will be
mounted at /api/v3/json/projects/:project_id/tickets rather than the /tickets URI if
you didn’t have it nested. Additionally, you’ve specified a dynamic parameter in the
form of :project_id. With this, you’ll be able to access the requested project id from
inside your Rack application using a method very similar to how you’d usually access
parameters in a controller.
If you attempted to run your spec again it would bomb out with another new error:
expected "[tickets array]"
got ""
This means that requests are able to get to your Rack app and that the response you’ve
declared is being served successfully. Now you need to fill this response with meaningful
data. To do this, find the project that’s being referenced in the URL by using the
parameters passed through found with the params method. Unfortunately, Sinatra
doesn’t load the parameters from your Rails application and so params[:project_id]
is not going to be set. You can see this if you change your root route in your Sinatra
application to this:
get '/' do
p params
end
Then if you run your test, you’ll see only the token parameter is available:
{"token"=>"6E06zoj01Pf5texLXVNb"}
Luckily, you can still get to this through one of the keys in the environment hash,
which is accessible through the env method in your Sinatra actions, like it was available
when you built your Rack applications. You saw this environment hash earlier
when you were developing your first Rack application, but this time it’s going to have
a little more to it because it’s gone through the Rails request stack. Let’s change your
root route to this:
get '/' do
p env.keys
end
When you rerun your test, you’ll see all the available keys output at the top, with one of
the keys being action_dispatch.request.path_parameters. This key stores the
parameters discovered by Rails routing, and your project_id parameter should fall
neatly into this category. Let’s find out by changing the p env.keys line in your root
route to p env["action_dispatch.request.path_parameters"] and then re-running
your test. You should see this:
{:project_id=>"3"}
Okay, so you can access two parameter hashes, but you’ll need to merge them
together if you are to do anything useful with them. You can merge them into a super