Tutorial
Step 1: Basic Resource
We’ll be working with a single database table, employees
:
id | first_name | last_name | age | created_at | updated_at |
---|---|---|---|---|---|
1 | Homer | Simpson | 39 | 2018-09-04 | 2018-09-04 |
2 | Waylon | Smithers | 65 | 2018-09-04 | 2018-09-04 |
3 | Monty | Burns | 123 | 2018-09-04 | 2018-09-04 |
The Rails Stuff 🚂
Use the built-in generator to create the database table
and corresponding ActiveRecord
model:
Now let’s seed some random development data, using Faker (which was installed in Step 0):
Run this seed file with
The Graphiti Stuff 🎨
Just like Rails, Graphiti has built-in generators. Let’s generate
the corresponding Resource for our Employee
model:
This generated a few things, but for now let’s focus on
EmployeeResource
:
This code defined the RESTful Resource we want our API to expose. Let’s run our server and see what it does:
Visit localhost:3000/api/v1/employees
. You should see a JSONAPI Response:
If you find the payload a little intimidating, add .json
to the URL for a more traditional response:
There’s .xml
, too:
These are all different renderings of the same EmployeeResource
.
Resources
are comprised of Attribute
s:
Each attribute defines behavior for:
- Reading (display)
- Writing
- Sorting
- Filtering
- Fieldsets
Let’s start with simple display, turning first_name
into all capital
letters:
Which gives us:
This is the most important thing to understand about Resources: they are just a collection of defaults, all of which can be overridden. In other words:
We’ll go into further Resource customizations over the course of this tutorial. For now, let’s just verify our out-of-the-box defaults:
- Sort by
first_name
ascending:http://localhost:3000/api/v1/employees?sort=first_name
- Sort by
first_name
descending:http://localhost:3000/api/v1/employees?sort=-first_name
- Return only
age
andcreated_at
in the response:http://localhost:3000/api/v1/employees?fields[employees]=age,created_at
- Filter on
first_name
:- Case-insensitive:
http://localhost:3000/api/v1/employees?filter[first_name]=bob
- Case-sensitive:
http://locahost:3000/api/v1/employees?filter[first_name][eql]=Bob
- Prefix:
http://localhost:3000/api/v1/employees?filter[first_name][prefix]=b
- Suffix:
http://localhost:3000/api/v1/employees?filter[first_name][suffix]=ob
- Contains:
http://localhost:3000/api/v1/employees?filter[first_name][match]=o
- Case-insensitive:
- Filter on
age
:- Equal:
http://localhost:3000/api/v1/employees?filter[age]=39
- Greater Than:
http://localhost:3000/api/v1/employees?filter[age][gt]=39
- Greater Than or Equal To:
http://localhost:3000/api/v1/employees?filter[age][gte]=39
- Less Than:
http://localhost:3000/api/v1/employees?filter[age][lt]=65
- Less Than or Equal To:
http://localhost:3000/api/v1/employees?filter[age][lte]=65
- Equal:
- Paginate
- 10 per page:
http://localhost:3000/api/v1/employees?page[size]=10
- 5 per page, third page:
http://localhost:3000/api/v1/employees?page[number]=3
- 10 per page:
Write operations are easiest to verify with integration tests, which
were created when we generated our Resource. Let’s take a look at the
test for creating Employee
s:
This is an API Spec, which tests high-level end-to-end functionality. We
know that if our API receives a POST with the given payload, an
Employee
will be created and a 201
response code will be returned.
API specs are high-level - often they won’t be changed past this initial boilerplate. For testing logic, use a Resource Spec. These integration tests hit the database and run logic, but operate without a specific request or response:
In other words: API specs test Endpoints (request, response, middleware, etc), Resource specs test only the Resource (actual application logic). Read more in our Testing Guide.
Before we run these specs, we need to edit our factories to ensure dynamic, randomized data. Let’s change this:
To
Now undo the capitalization change to attribute :first_name
, and run the generated specs:
You’ll see 11 tests pass, with 3 pending. One of the pending specs was
autogenerated by rails - you can delete spec/models/employee_spec.rb
for now.
That leaves us with two “update” specs. These are marked pending so you can manage the data yourself. Follow the comments in these specs to add attributes and get them passing.