When one resource belongs to another resource, you can add it as a nested resource. In the blog, comments belong to posts. Here’s how you represent that in config/routes.rb:

resources :posts do
  resources :comments
end

Add a block after resources :posts with a do, end pair. Then add resources :comments inside that block. This tells Rails that comments are only available inside of posts.

Adding resources :comments as you just saw creates routes for each of the seven default RESTful actions for comments. For now, let’s only worry about creating new comments. You can restrict the set of routes generated for a resource by adding an only clause to that resource in config/routes.rb:

resources :posts do
  resources :comments, only: :create
end

Now, only the comment create action is mapped to a URL. You should only provide routes to actions that you plan to implement.

Parameters generally represent part of the URL used to request a page or values from a form, and they’re accessible in the controller as a hash named params. For example, the set_post method you saw earlier retrieved the id of the requested post from the params hash, like this:

@post = Post.find(params[:id])

You can see the parameters passed with each request in the output from the rails server command in your terminal. For example, go to http://localhost:3000/posts/1 and then look at the Rails server output in your terminal:

  Started GET "/posts/1" for 127.0.0.1 at 2014-03-31 20:30:03 -0500
  Processing by PostsController#show as HTML
➊   Parameters: {"id"=>"1"}
    Post Load (0.3ms) SELECT "posts".* FROM "posts"
      WHERE "posts"."id" = ? LIMIT 1 [["id", "1"]]
    Rendered posts/show.html.erb within layouts/application (233.9ms)
  Completed 200 OK in 274ms (Views: 245.5ms | ActiveRecord: 26.2ms)

In this case, the 1 in the URL represents the id of the requested post ➊. Because we requested a single post, the show method is called, and this id is used to find the post in set_post.

Form data is represented by a nested hash with values. For example, editing this post results in a params hash more like this:

  {
    "utf8"=>"✓",
    "authenticity_token"=>"...",
➊   "post"=>{"title"=>"First Post", "body"=>""},
    "commit"=>"Update Post",
➋   "id"=>"1"
  }

You still access params[:id] ➋ to find the correct post, and you can also access params[:post] ➊ to see the new values submitted by the user. Because these are user-submitted values, you should ensure that your application only accepts data for the appropriate attributes. Malicious users could send requests with invalid parameters in an attempt to attack your application.

For blog posts, you only want users to be able to edit the title and body attributes. Rails includes a feature called Strong Parameters, which makes specifying which attributes your application accepts easy. You can see the feature in action in the post_params method:

def post_params
  params.require(:post).permit(:title, :body)
end

This method first requires the params hash to contain a nested hash with the key :post. It then returns only the permitted values (:title and :body) from this nested hash. Using the earlier example params hash, post_params returns a hash like this:

{"title" => "First Post", "body" => ""}

Other values in the params[:post] hash are silently ignored. Remember, always use the post_params method when accessing the parameters for a newly created or updated post.

Every action must either render a view or redirect to another action. By default, an action renders a file matching the action name. For example, the show method in the posts controller looks for a file named app/views/posts/show.html.erb and uses that file to build the HTML response that is sent back to the user.

You can tell Rails to render the response for a different action with the render method like this:

render action: "edit"

The ability to specify actions is helpful if you need to render a different view based on user input. This example is from the update method. If the post could not be updated with the data provided by the user, this method renders the edit view again, giving the user a chance to correct the data.

Sometimes you need to send the user to a page other than the one he or she requested. Use the redirect_to method to take care of this. For example, if the user enters valid data while creating or updating a post, the controller action redirects the user to that post:

redirect_to @post

When you call redirect_to, the address in the user’s browser changes to reflect the new page, and another request is made. You can see this by watching the address bar as you submit form data and by looking at the output from rails server in your terminal.

To see this in action, first go to http://localhost:3000/posts/new in your browser. This is the new post form. Enter a title for the new post, and then click the Create Post button. Watch the address bar closely after clicking the button.

The form makes a POST request to http://localhost:3000/posts. This request is routed to the create method. After creating the post, you are redirected to http://localhost:3000/posts/3, assuming that your new post has an id of 3. The address is changed automatically by the redirect_to method.

Rails can generate responses in several formats, though all I’ve discussed so far is HTML. Scaffold-generated controllers can also include JavaScript Object Notation (JSON) responses, which are useful for creating application programming interfaces (APIs). Other formats include XML and even PDF.

You can try another response type in your web browser by visiting this URL: http://localhost:3000/posts.json. This URL is the same as the posts index URL used earlier, except it has .json added to the end. Rails recognizes this as a JSON request and renders the collection of posts as JSON, as in Figure 4-1.

Figure 4-1. Posts in JSON format

You specify the formats an action accepts and the responses to each format with a call to the respond_to method. This method accepts a block with a single parameter representing the requested format. Here is an example from the destroy method:

respond_to do |format|
 format.html { redirect_to posts_url }
 format.json { head :no_content }
end

This method is called right after a post is destroyed. If the client requests HTML data, this block redirects to posts_url, the index page. If the client requests JSON data, by adding .json to the end of the URL, this block responds with an empty header to indicate the post no longer exists.

Flash messages are alerts to the user that are only valid for a single request. Flash messages are stored in the user’s session, typically in a cookie. They are usually styled differently to stand out. For example, the stylesheet included with Rails scaffolding uses green text for flash messages.

Flash messages are helpful for sending error messages or other notifications to the user. They are generally set on a redirect. Here’s an example from the create method in the posts controller:

redirect_to @post, notice: 'Post was successfully created.'

When a post is successfully created, the user is redirected to the new post and a flash message like the one in Figure 4-2 is shown.

Figure 4-2. A flash message

The create flash message is the green text, and it matches the message added earlier.