Thank you for visiting my Tea Service API. This is a takehome challenge given by Turing School of Software and Design.
The purpose of this takehome challenge is to create endpoints for a Front End team to consume.
- Subscribe a Customer to a Tea Subscription
- Cancel a Customer's Tea Subscription
- See all of a Customer's Subscriptions both active and cancelled
-
8 hours to create 3 endpoints
-
Clear Documentation
-
Project Boards Used
-
Restful Routes only
-
Full TDD
-
Explain OOP design descions
- I decided to use Subscriptions as the connection between customers and tea, instead of having multiple joins tables, I was able to use a minimal database to accomplish my task.
- fork then clone the
tea-service repository - move into the directory by entering
cd tea-service - install the gemfile with
bundle install - setup the database with
rails db:{create,migrate,seed} - start your server with
rails sit is setup to be run onlocalhost:3000
- I decided to use CircleCI for my project to make sure that my PR would not muddle my existing code. After each check that was green, I knew my code was good to deploy.
POST /api/v1/customers/1/subscriptions
Sending a POST request to the endpoint, will create and save a JSON response for the FE team.
{
"data": {
"id": "1",
"type": "subscription",
"attributes": {
"title": "Foe Hammer Kick = weekly subscription for Luke",
"price": 400,
"frequency": "weekly",
"status": "active"
}
}
}PATCH /api/v1/customers/1/subscriptions/1
Sending a PATCH request, will update the customers subscription to either active or cancelled.
{
"data": {
"id": "1",
"type": "subscription",
"attributes": {
"title": "Foe Hammer Kick = weekly subscription for Luke",
"price": 400,
"frequency": "weekly",
"status": "cancelled"
}
}
}GET /api/v1/customers/1/subscriptions
Sending a GET request to the endpoint, will return the proper JSON response.
{
"data": [
{
"id": "1",
"type": "subscription",
"attributes": {
"title": "Foe Hammer Kick = weekly subscription for Luke",
"price": 400,
"frequency": "weekly",
"status": "active"
}
},
{
"id": "1",
"type": "subscription",
"attributes": {
"title": "Apolyon, the Soul-Render = weekly subscription for Luke",
"price": 400,
"frequency": "weekly",
"status": "active"
}
}
]
}If I were to consume the API information for individual teas, I would go through this path.
- Create a Service for the Tea using the Faraday Gem.
- Create a Facade to properly format the request with a Poro.
- Save the Tea that is requested to the Customers list.
- I would not save the data to my own database.
- I would build out an error serializer method for tea in cases where the API is not available.
- I would format the Tea API JSON to fit my input and I would create a Tea controller and model.
- I believe this would fully consume the API for our purposes.
CORS is actually not very difficult to introduce to your codebase.
- gem 'rack-cors' is preloaded into the ruby gemfile
- uncomment it
- add config code to helper files
- push to database
I would utilize Heroku or another free to deploy service.
- Setup database on Heroku and connect it with my code.
- Allow for Github CD in the settings menu.
- Continue to Monitor it when uploading new code to the main branch.