A template for starting projects with rails-api. Includes authentication.
At the beginning of each cohort, update the versions in Gemfile.
Install with bundle install.
- Download this template.
- Unzip and rename the template directory (
unzip ~/Downloads/rails-api-template-master.zip) - Move into the new project and
git init.
- Empty
README.mdand fill with your own content. - Rename your app module in
config/application.rb(changeRailsApiTemplate). - Rename your project database in
config/database.yml(change'rails-api-template').
- Install dependencies with
bundle install. git addandgit commityour changes.- Create a
.envfor sensitive settings (touch .env). - Generate new
developmentandtestsecrets (bundle exec rails secret). - Store them in
.envwith keysSECRET_KEY_BASE_<DEVELOPMENT|TEST>respectively. - In order to make requests to your deployed API, you will need to set
SECRET_KEY_BASEin the environment of the production API (for example, usingheroku config:setor the Heroku dashboard). - In order to make requests from your deployed client application, you will
need to set
CLIENT_ORIGINin the environment of the production API (for example,heroku config:set CLIENT_ORIGIN=https://<github-username>.github.io). See more about deploying to heroku rails-heroku-setup-guide
- bin/rails db:drop (if it already exists)
- bin/rails db:create
- bin/rails db:migrate
- bin/rails db:seed
- bin/rails db:examples
Note: Do this for each database you want to set up. Your local database and production (Heroku) database will both need to be set up in this way!
- Run the API server with
bin/rails serverorbundle exec rails server.
This template follows the standard project structure in Rails.
curl command scripts are stored in curl-scripts with names that
correspond to API actions.
User authentication is built-in.
Tests (also called specs) are located in the spec folder.
Developers should run these often!
bin/rails routeslists the endpoints available in your API.bin/rspec specruns automated tests located in thespecfolder.bin/rails consoleopens a REPL that pre-loads the API.bin/rails dbopens your database client and loads the correct database.bin/rails serverstarts the API.curl-scripts/*.shrun variouscurlcommands to test the API. See below.
Use this as the basis for your own API documentation. Add a new third-level heading for your custom entities, and follow the pattern provided for the built-in user authentication documentation.
Scripts are included in curl-scripts to test built-in actions. Add your
own scripts to test your custom API. As an alternative, you can write automated
tests in RSpec to test your API.
| Verb | URI Pattern | Controller#Action |
|---|---|---|
| POST | /sign-up |
users#signup |
| POST | /sign-in |
users#signin |
| PATCH | /change-password |
users#changepw |
| DELETE | /sign-out |
users#signout |
Request:
curl http://localhost:4741/sign-up \
--include \
--request POST \
--header "Content-Type: application/json" \
--data '{
"credentials": {
"email": "'"${EMAIL}"'",
"password": "'"${PASSWORD}"'",
"password_confirmation": "'"${PASSWORD}"'"
}
}'EMAIL=ava@bob.com PASSWORD=hannah curl-scripts/auth/sign-up.shResponse:
HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
{
"user": {
"id": 1,
"email": "ava@bob.com"
}
}Request:
curl http://localhost:4741/sign-in \
--include \
--request POST \
--header "Content-Type: application/json" \
--data '{
"credentials": {
"email": "'"${EMAIL}"'",
"password": "'"${PASSWORD}"'"
}
}'EMAIL=ava@bob.com PASSWORD=hannah curl-scripts/auth/sign-in.shResponse:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
{
"user": {
"id": 1,
"email": "ava@bob.com",
"token": "BAhJIiVlZDIwZTMzMzQzODg5NTBmYjZlNjRlZDZlNzYxYzU2ZAY6BkVG--7e7f77f974edcf5e4887b56918f34cd9fe293b9f"
}
}Request:
curl --include --request PATCH "http://localhost:4741/change-password" \
--header "Authorization: Token token=$TOKEN" \
--header "Content-Type: application/json" \
--data '{
"passwords": {
"old": "'"${OLDPW}"'",
"new": "'"${NEWPW}"'"
}
}'OLDPW='hannah' NEWPW='elle' TOKEN='BAhJIiVlZDIwZTMzMzQzODg5NTBmYjZlNjRlZDZlNzYxYzU2ZAY6BkVG--7e7f77f974edcf5e4887b56918f34cd9fe293b9f' sh curl-scripts/auth/change-password.shResponse:
HTTP/1.1 204 No ContentRequest:
curl http://localhost:4741/sign-out \
--include \
--request DELETE \
--header "Authorization: Token token=$TOKEN"TOKEN='BAhJIiVlZDIwZTMzMzQzODg5NTBmYjZlNjRlZDZlNzYxYzU2ZAY6BkVG--7e7f77f974edcf5e4887b56918f34cd9fe293b9f' sh curl-scripts/auth/sign-out.shResponse:
HTTP/1.1 204 No ContentRemember, creating and applying migrations are two different things. After you create a migration (one of those files that lives in db/migrate/), you need to apply it to each database using bin/rails db:migrate (local) or heroku run rails db:migrate (production).
Sometimes you need to revert a migration that you already applied. There are many ways to revert your database to a previous state, and one of the most common is simply rolling back (reverting) the last migration that you ran. Read more in the Rails Guide
If you don't want to completely reset the database (maybe you have data you want to preserve?), you have other, less destructive options. One is rolling back a specific migration by specifying the VERSION that the database should revert to. Ask a consultant if you need assistance, as database commands like these are non-reversable.
To rerun all migrations, starting from VERSION=0, you would do:
bin/rails db:migrate VERSION=0
bin/rails db:migrate db:seed db:examplesTo run this command (and others like this) on Heroku, just append heroku run before the rails command.
- All content is licensed under a CCBYNCSA 4.0 license.
- All software code is licensed under GNU GPLv3. For commercial use or alternative licensing, please contact legal@ga.co.