Rails%203%20In%20Action

350 CHAPTER 13 Designing an API
critical role in an API, providing key information such as if the request was successful
(the 200 status code) or if the user is unauthorized (the 401 status code) to perform
the request. These are standardized ways of quickly informing people of the result of
their requests.
TIP There’s a handy gem called cheat that provides cheat sheets for a
number of things, including one for HTTP status codes. You can install
this gem using the gem install cheat command and then bring up the
cheat sheet for status codes using cheat status_codes.
But if you’re on Windows, this won’t work because Cheat requires a
function not found on your system. Instead, go to http://cheat
.errtheblog .com/b where you can view the list of all the cheat sheets.
To begin writing this API, you’ll need to define the routes to it. Without routes, making
requests to /api/v1/projects.json will forever be fruitless. If you recall from this chapter’s
introduction, the API URL that you’ll be using looks like /api/v1/projects.json. Previously,
when you wanted URLs to be prefixed with a name (such as back in chapter 7),
you used a namespace method for them. You’re going to do the same thing here,
except you’ll use a namespace within another namespace. Let’s open config/routes.rb
and add the code from the following listing to the top of the routes definition.
Listing 13.1 config/routes.rb
Ticketee::Application.routes.draw do
namespace :api do
namespace :v1 do
resources :projects
end
end
...
This new route defines routes and routing helpers for the projects resources, such as
/api/v1/projects, and api_v1_projects_path respectively. You’re going to need to
be serving content from this route, namely a list of projects. This list will be served in
one of two forms: XML or JSON. Before you actually implement the code that makes
these responses get served, you’re going to write a new RSpec test that makes sure
these routes return the right data. To help you along, you’ll be using a feature provided
by one of the dependencies of Rails: the rack-test gem.
This gem provides a module called Rack::Test::Methods, which contains methods
such as get, post, put, and delete. Look familiar? They should. They’re the four
basic HTTP methods that you use when making requests. The methods from
Rack::Test::Methods take a path on which to make a request and then return a Rack
response (an Array) that consists of three parts: the HTTP status code, the HTTP headers
(in Hash form), and the body. The simplest Rack response would look something
like this:
[200, {}, "Hello World!"]