In this project, you’ll get a chance to interact with a Rails application from the command line by sending requests manually. You’ll first build a very simple app (to get some practice with the steps involved in creating a new one) and then a simple script which uses the RestClient gem (which you used in the first project) to send some requests and examine the server output.
There’s a lot of steps but it’s actually quite straightforward.
First you need to create a simple Rails app:
$ rails newcommand?). Go (
cd) into the application folder and open it up in a text editor.
config/routes.rband add the users resources with
$ rake routes
Next create a simple script file which will run RestClient and allow you to start pinging your new app:
app/script/rest_requestor.rb. You’ll probably need to create a new folder. This
scriptfolder is just a convenient place to store our scripts, which we’ll be calling explicitly from the command line. There’s nothing special about it.
What’s the simplest way to make a request? Just use the
#get method of
#puts that output to the terminal:
# app/script/rest_requestor.rb require 'rest-client' url = "http://localhost:3000" puts RestClient.get(url)
#chompto allow you to enter input from the command line.
$ ruby script/rest_requestor.rb. Error! You don’t have anyone waiting for the request.
$ rails server
http://localhost:3000/usersinstead. Run it again.
404 Resource Not Found. Your application is throwing an error, but why? Go to the tab that is running your server and check the server logs. You should see something saying
ActionController::RoutingError (uninitialized constant UsersController):on top of a long stack trace. Okay, it’s looking for a controller, that makes sense… we don’t have one.
app/controllers/users_controller.rb(just remember to have it inherit from
ApplicationController), or you could also create it using one of the Rails generators on the command line (which just plops out a bunch of files). Try
app/views/users. You can avoid generating the test files (it makes no difference for this) by adding
--no-test-frameworkto the end of the generator command.
AbstractController::ActionNotFound (The action 'index' could not be found for UsersController):. It sure seems like the request was routed to the controller and, as you’d expect for a
/usersURL, it’s looking for the
#indexaction but it couldn’t find the action. That’s because we haven’t created the methods yet in our controller.
Create the 4 methods that correspond to GET requests. Each method should set an instance variable to display the method name:
# app/controllers/users_controller.rb def index @name = "I am the Index action!" end
ActionView::MissingTemplate (Missing template users/index.... That sounds like a view error… but of course. You know that the index action would complete and then automatically go looking for the
app/views/users/index.html.erbview file to render.
Fix this by creating a view file for each of the 4 actions that require it. It should put the action’s name in
<h1> tags, e.g.:
# app/views/users/index.html.erb <h1><%= @name %></h1>
app/views/layouts/application.html.erb, including lots of turbolinks calls but then, near the bottom, you should see your lonely
app/views/layouts/application.html.erbfile and add some arbitrary HTML tags before and after the
<%= yield %>line and rerun your request to see where they pop up in the returned HTML.
#show), you’ll need to include an ID value in the URL (which we won’t actually be using).
#createaction in your controller, which would be accessed using a POST request. Update your script to make a simple POST
#postrequest sending no data, e.g.
RestClient.post(url,""). See the RestClient Docs for info on how to structure the non-GET requests.
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):. Aha! Rails doesn’t like it when you try to make POST requests to your application using the command line since POST requests typically represent the submission of form data which may be sensitive. The same is true for DELETE and PATCH requests.
We’ll get more into this in the lesson on forms, but basically Rails will send a special token code when it renders a form in the webpage and then it only accepts the response if the form sends back that token with the submission. Since you are operating directly from the command line and never got that original token, Rails won’t accept your request. Food for thought.
Hopefully this has been a useful adventure into the request cycle of a Rails app and given you a chance to get a bit familiar with basic app creation and setup and routing. Feel free to send feedback.
In this chapter of the tutorial you will build out the look and feel of the application using Twitter’s Bootstrap CSS framework. If you’re feeling shaky on CSS, check out the CSS Lesson in the Web Development 101 course.
Bootstrap will do a lot of the heavy lifting for you – instead of having to figure out how to make your navbar stick to the top of the screen, you just have to put the correct class onto some
<div> tags and Bootstrap’s style files will take over for you. It’s a good way to quickly get something half decent up and running. In the course on HTML and CSS, you’ll get the chance to design your own CSS framework, but for now Bootstrap is a good weapon of choice.
This section contains helpful links to other content. It isn’t required, so consider it supplemental for if you need to dive deeper into something.