Layla - Edges - Muncher

[lbristol88]

API Muncher

Congratulations! You're submitting your assignment!

Comprehension Questions

Question	Answer
How did you go about exploring the Edamam API, and how did you try querying the API?	I read the docs, signed up for an ID and key on the API i wanted to use and then used postman.
What is an API Wrapper? Why is it in lib? How would your project change if you needed to interact with more than one API (aka more than just the Edamam API)?	If I wanted to interact with more than one API, I would create multiple API wrappers. The wrappers are located in lib because it's not part of the web app, it's something we need to get the data. The API wrapper is how we access the websites api and choose what information we want specifically from the API.
Describe your API wrapper, the methods you created in it, and why you decided to create those methods/how they were helpful	I created methods in the API wrapper to both search and get the recipes from the API, and also to parse the information received from the API. I needed to parse the responses because I had to take the format that they had it in, into a format that is useable in my app.
What was an edge case or failure case test you wrote for your API Wrapper? What was a nominal case?	I made tests to see if the wrapper can do a recipe search and parse the api. The tests also check to verify if it can parse an api response and parse a single recipe.
How does VCR aid in testing an API?	VCR lets you create test data that can be run multiple times without accessing the API with every request. This allows you not to exceed the number of requests granted by the API without having to pay a fee.
What is the Heroku URL of your deployed application?	https://muncherr.herokuapp.com/

[droberts-sea]

API Muncher

What We're Looking For

Feature	Feedback
Core Requirements
Git hygiene	yes
Comprehension questions	yes
General
Rails fundamentals (RESTful routing, use of named paths)	almost - see inline
Semantic HTML	yes
Errors are reported to the user	no - A search with no hits results in a blank page, and mangling the URI on the show page results in an exception rather than a polite error message. Getting a good handle on error handling is not just good for your users, it will also make your life easier as a developer.
API Wrapper to handle the API requests	yes - good use of helper methods, though the interface could be cleaner
Controller testing	some - missing failure cases
Lib testing	some - missing failure cases
Search Functionality	yes
List Functionality	yes
Show individual item functionality	yes
Styling
List view shows 10 items at a time and/or has pagination	yes
Attractive and usable UI	yes
API Features
The App attributes Edamam	yes
The VCR cassettes do not contain the API key	yes
External Resources
Link to deployed app on Heroku	yes
Overall	Good work overall. This app is attractive and functional, and it's clear that the core learning goals around working with an API and mocking an external resource were met. I would like to see more test coverage, and there are a few inline things that could be cleaned up, but in general I'm quite happy with this submission. Keep up the hard work.

[droberts-sea]

Why not resources :recipes, only: [:index, :show]?

[droberts-sea]

Instead of storing this data in a hash, you should define a Recipe class. That would allow your views to treat it the same as an ActiveRecord model.

[droberts-sea]

This code would be a little cleaner if, instead of having to call two methods in sequence, you had one method that did all the work.

[droberts-sea]

Should this method be private?

[droberts-sea]

What if the search turns up no results?

[droberts-sea]

This should not be under the search describe block.

Missing case: what if the URI is bad?