Tasked with building out ReST, relational, single-finders, multi-finders, and buisness intelligence endpoints for a simple e-commerce site.
- Ruby on Rails API
- Responses serialized adherent to JSON 1.0 industry standards
- Test Driven Development with ~100% coverage in RSpec Test Suite
- Focus on MVC design principals and ReST
- Expose an API
- Use serializers to format JSON responses
- Test API exposure
- Compose advanced ActiveRecord queries to analyze information stored in SQL databasese
- Write basic SQL statements without the assistance of an ORM
Pre Built Front End test suite Rails Driver
git clone [email protected]:turingschool-examples/rails_driver.git
cd rails_driver
bundle
(if this fails, try tobundle update
and then retry)rails db:create
&&rails db:migrate
bundle exec figaro install
- In
config/application.yml
addRAILS_ENGINE_DOMAIN: http://localhost:3000
to set up the server port.
From the same root level as rails_driver
:
git clone [email protected]:sienna-kopf/my-api.git
cd my_api
bundle install
The my_api
application is fully tested using RSpec reporting ~100% test coverage determined by SimpleCov.
To run the test suite, setup the application and run bundle exec rspec
in the terminal. To run a specific test run bundle exec rspec <test file path>
. To open the coverage report generated by SimpleCov run open coverage/index.html
.
To run the front-end Test Suite, Rails Driver, setup that applicaition and run bundle exec rspec
in the terminal. There should be 16 passing tests and one failing test for a buisness intelligence endpoint.
Postman is recommended, but any API platform that allows you to run enpoint queries with query params, headers, and a request body will do!
In my_api
run rails s
to start the server. This will give you a port URL, something like http://localhost:3000
, which is the main URI path for all the endpoint queries. In your API platform, the base URL will look like http://localhost:3000/api/v1/<endpoint>
because all current endpoints are part of the first version of the API, and are therefore namespaced as such.
To run the items
index endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/items
with the request method type set to GET
.
In Postman, the setup for this endpoint looks like:
The response for this endpoint is a JSON 1.0 standard display of all of the items seeded into the database, including name, description, unit_price, and merchant_id for each item. A sample of this response looks like:
To run the items
create endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/items
with the request method type set to POST
. For this endpoint, we also need to send a request body with the new items name, description, unit_price, and merchant_id. In Postman, we will include this information as JSON under the body tab like this:
The response for this endpoint is a JSON 1.0 standard display of the details for the item that was just created, including name, description, unit_price, and merchant_id for each item. For this example the response looks like:
To run the merchant/:id/items
merchant-items endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/merchant/:id/items
with the request method type set to GET
. The path variable :id
should be set to an existant merchant id in the database. In Postman, the setup for this endpoint looks like:
The response for this endpoint is a JSON 1.0 standard display of all of the items seeded into the database with that merchant as an associated foreign key, including name, description, unit_price, and merchant_id for each item. A sample of this response looks like:
To run the merchants
delete endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/merchants/:id
with the request method type set to DELETE
. The path variable :id
must be set to an existant merchant in the database. In Postman, this setup looks like:
The response for this endpoint sends a 204 HTTP status code:
The deletion of a merchant
from the database triggers a series of dependecy deletes for any invoices
, invoiceItems
, payments
, and items
associated in a dependent fashion to that merchant
.
This can be demonstrated by establishing that a merchant
has many items through the merchants/:id/items
endpoint. This might look like:
Then, when that merchant is deleted, a search for any of the items displayed under the merchant items endpoint display a 204 no content error. The same is true for other associated objects such as invoices
, payments
, and invoiceItems
:
To run the items/find
item single-finder endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/items/find
with the request method type set to GET
. A query parameter should be included based on the attributes of the resource, for item name, description, unit_price, merchant_id, or created_at / updated_at date. This parameter would look something like "name=distinct" or "unit_price=42.91". Name and description are case insensitive character inclusion searches so if the name of an item is "Item Distinctio" a query for "Distinctio", "distinctio", "distinct" etc will all work. unit_price
, created_at
and updated_at
dates, and merchant_id
are all exact finders, and much be matched exactly for an appropriate response. In Postman, the setup for this endpoint might look something like:
The response for this example is a JSON 1.0 standard display of a single item in the database that matches the search. In this example, the response looks like:
To run the merchants/find_all
merchant multi-finder endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/merchants/find_all
with the request method type set to GET
. A query parameter should be included based on the attributes of the resource, for merchants the searchable attributes are name and created_at/updated_at date. This parameter would look something like "name=sons". Name is a case insensitive character inclusion search so if the name of an merchant is "Willms and Sons" a query for "Sons", "sons", "son" etc will all work. created_at
and updated_at
dates are exact finders, and much be matched exactly for an appropriate response. In Postman, the setup for this endpoint might look something like:
The response for this example is a JSON 1.0 standard display of all merchants in the database that match the search. In this example, a sample of the response looks like:
To run the merchants/:id/revenue
merchant revenue endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/merchants/:id/revenue
with the request method type set to GET
. The path varible :id
should be set to the id of a merchant in the database. In Postman, the setup for this endpoint looks like:
The response for this endpoint is a JSON 1.0 standard display of all of the revenue for that particular merchant. In this example, the repsonse looks like:
The ActiveRecord Query required for this endpoint involved joining a merchants invoices
through the invoiceItems
table all the way to payments
in order to select the aggregate revenue of only successfully paid for and shipped items. The method that handles this ActiveRecord query and creation of a Revenue object to be serialized looks like:
To run the merchants/most_revenue
merchants with most revenue endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/merchants/most_revenue
with the request method type set to GET
. The query parameter quantity
should be set to the number of merchants desired in the return -- for example "quantity=2". In Postman, the setup for this endpoint looks like:
The response for this endpoint is a JSON 1.0 standard display of the top x merchants by total revenue. In this example, the repsonse looks like:
The ActiveRecord Query required for this endpoint involved joining a merchants invoices
through the invoiceItems
table all the way to payments
in order to select the merchants data along side aggregate revenue of only successfully paid for and shipped items. The list of merchants was then limited by the quantity
query param. The method that handles this ActiveRecord query looks like:
To run the merchants/most_items
merchants with most items endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/merchants/most_items
with the request method type set to GET
. The query parameter quantity
should be set to the number of merchants desired in the return -- for example "quantity=2". In Postman, the setup for this endpoint looks like:
The response for this endpoint is a JSON 1.0 standard display of the top x merchants by item count. In this example, the repsonse looks like:
The ActiveRecord Query required for this endpoint involved joining a merchants invoices
through the invoiceItems
table all the way to payments
in order to select the merchants data along side the aggregate total invoiceItems of only successful payments for and shipped invoices. The list of merchants was then limited by the quantity
query param. The method that handles this ActiveRecord query looks like:
Below a screen cast is attached running through all the endpoints of the project:
- FastJsonAPI
- Faker
- Shoulda-Matchers
- Factory Bot Rails
- RSpec
- Pry
- SimpleCov
- PostgreSQL