The final project of the third quarter (Mod 3) of the Turing School--five-day duration.
Based upon wireframe guidelines and example payloads for a fake weather and activity planning site (project specs), endpoints for complex weather data, user authentication and authorization, and climbing and road trip activity planning were built out by interacting with the MapQuest, Mountain Project, Pixabay, and Open Weather APIs.
- Ruby on Rails API
- Responses serialized adherent to JSON 1.0 industry standards
- Test Driven Development with 100% coverage in RSpec Test Suite
- Continuous Integration with Travis CI
- Deployment to Heroku
- Focus on MVC design principals and REST
- Expose an API that aggregates data from multiple external APIs
- Expose an API that requires an authentication token
- Expose an API for CRUD functionality
- Determine completion criteria based on the needs of other developers
- Research, select, and consume an API based on your needs as a developer
- clone and setup
sweater_weatherlocallybundle installrails db: createrails db: migraterails db: seed
Run bundle exec figaro install to trigger the creation of a /config/application.yml file for configuring API keys.
Sign up for the following API:
OpenWeather
Add the following code snippet to your /config/application.yml file.
Make sure to insert the key without the alligator clips ( < > ).
OPEN_WEATHER_API_KEY: "<insert>"
Sign up for the following API:
Pixabay
Add the following code snippet to your /config/application.yml file.
Make sure to insert the key without the alligator clips ( < > ).
PIXABAY_API_KEY: "<insert>"
Sign up for the following API:
MapQuest
Add the following code snippet to your /config/application.yml file.
Make sure to insert the key without the alligator clips ( < > ).
MAP_QUEST_API_KEY: "<insert>"
Sign up for the following API:
Mountain Project and click Sign Up
Add the following code snippet to your /config/application.yml file.
Make sure to insert the key without the alligator clips ( < > ).
MOUNTAIN_PROJECT_API_KEY: "<insert>"
Postman is recommended, but any API platform that allows you to run enpoint queries with query params and a request body will do!
In sweater_weather 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 forecast endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/forecast and the query parameter you would include/append is location=<city, state code> something like "denver, co". The method for this endpoint is a GET which should also be set before running in the API platform.
In Postman, the setup for this endpoint looks like:
When run, the response returns the current weather:
Eight hours worth of hourly forecast:
And six days worth of daily forecast:
Filtering the attributes included in each response based upon the wireframe for this endpoint:
To run the users endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/users with the method set to POST. For this endpoint, we also need to send a request body with the users email, password, and password confirmation. In Postman, we will include this information as JSON under the body tab like this:
When run, the endpoint will return a JSON 1.0 standard response that includes the new users id, email, and an randomly generated api_key to handle authentication. This response looks like this:
For this endpoint, there is numerous sad paths built in all of which offering a standard JSON 1.0 format response, a helpful error message, and a corresponding status code. The first sad path for this endpoint concerns a failure of email uniqueness:
The second sad path concerns password / password confirmation mismatch:
These sad paths are important catches in making sure that the application is used properly.
To run the road_trip endpoint, the URL in your API platform would look like http://localhost:3000/api/v1/road_trip with the method set to POST. For this endpoint, we also need to send a request body with a origin, destination, and authenticated users unique api_key. In Postman, we will include this information as JSON under the body tab like this:
When run, the endpoint will return a standard JSON 1.0 response that synthesizes the following information per the project specs:
- a data attribute, under which all other attributes are present:
- id, always set to null
- type, always set to “roadtrip”
- attributes, an object containing road trip information:
- start_city, string, such as “Denver, CO”
- end_city, string, such as “Estes Park, CO”
- travel_time, string, something user-friendly like “2 hours, 13 minutes” or “2h13m” or “02:13:00” or something of that nature (you don’t have to include seconds); set this string to “impossible route” if there is no route between your cities
- weather_at_eta, conditions at end_city when you arrive (not CURRENT weather), object containing:
- temperature, numeric value in Fahrenheit
- conditions, string, as given by OpenWeather
For the input of "denver, co" as origin and "pueblo, co" as destination, the response looks like:
This endpoint also has sad paths built to send a 401 Unathorized status code if the api_key sent in the body is invalid or nonexistant.
Below a screen cast is attached running through all the endpoints of the project:
The sweater_weather 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.
- Figaro
- Faraday
- FastJsonAPI
- Bcrypt
- VCR
- WebMock
- Shoulda-Matchers
- GitHub
- RSpec
- Pry
- Launchy
- Capybara
- SimpleCov
- PostgreSQL