Queues - Elizabeth Deutsch - API-Muncher

[edeutschie]

API Muncher

Congratulations! You're submitting your assignment!

Comprehension Questions

Question	Answer
How did you go about exploring the Edamam API, how did you try querying the API?	I started by looking at the documentation for the Recipe Search API side of Edamam. I read up on the different parameters that are available and how they are identified for each recipe search. I used Postman to start querying the API after I got my app_key and app_id. Seeing how the information was sent back by Postman helped me further to see how to access the information through the API-Muncher program.
Describe your API Wrapper. How did you decide on the methods you created?	My API Wrapper has three methods. 1. It initializes a recipe search (as an instance of the class EdamamRecipes) with the instance variables of @uri, @Label, @image. 2. It has a self.get_recipes method which queries the API with 3 parameters (the search request, the from point, and the to point). The last two parameters were added when I was working on the pagination part of the project. The get_recipes method stores the result of the query as an array of the many recipes found in a search. These can be displayed by the index method of the recipes controller. 3. The third is the self.find_recipe method which takes the parameter of the URI of the recipe the user selects. The method passes that unique uri (as the id of the recipe) into an HTTParty request and the recipe and it's info is stored and available to the show method of the recipes controller to display on a show page.
Describe an edge case or failure case test you wrote for your API Wrapper.	A good failure case test for my API Wrapper would be a test for the find_recipe method that tests what happens when an invalid uri is passed in as a parameter.
Explain how VCR aids in testing an API.	VCR aids in testing an API by recording a response request cycle for each test between the program and the API. It then plays back that response from the API if the test is run again. The benefit is that the API is not contacted every time a test is run which saves the app from running out of it's allowance of free requests and saves money if you are paying for each request.
What is the Heroku URL of your deployed application?	https://api-muncher-elizabeth.herokuapp.com/
Do you have any recommendations on how we could improve this project for the next cohort?

[PilgrimMemoirs]

API Muncher

What We're Looking For

Feature	Feedback
Core Requirements
Git hygiene	Well Done
Comprehension questions	Well Done
General
Rails fundamentals (RESTful routing, use of named paths)	Well Done
Semantic HTML	Well Done
Errors are reported to the user	Sometimes - it doesn't show an error if I throw in a wrong uri for a recipe show.
API Wrapper to handle the API requests	Well Done
Controller testing	Well Done
Styling
Foundation Styling for responsive layout	Well Done - the last element of the list, on the smaller screen, goes to the right instead of staying on the left with the other recipe elements, how can you tell foundation to have it stay left? That problem can also be alleviated with the block grid.
Search View	Well Done
List View	Well Done
Show View which opens in a new tab	Mostly good - The header taking over the full viewport on load makes it appear like it went back to the search view, I almost did think to scroll to look for the show content. Perhaps the header could be smaller on pages that aren't the search. Should also continue to use foundation grid to organize content.
API Features
The App attributes Edaman	Well Done
The VCR casettes do not contain the API key	Well Done
Overall
	Great work accomplishing the required tasks. My biggest suggestion would be to still display an error to a user if the uri for a recipe is not valid on the recipe show. Also be mindful of how content is displayed on a site - the most important information should take over the viewfinder on page load.