Project 2
The goal of this project was to create a vignette about contacting an API using functions that my groupmate and I created to query, parse, and return well-structured data. Then, the functions were to be used to obtain data from the API to do some exploratory data analysis (EDA.) My groupmate and I initially elected to use a brewery API and did some initial work with querying and parsing data from that API. What became apparent after a while was that the brewery API lacked numerical data that would be needed for creating the plots needed for our EDA. We chose to abandon the brewery API, shifted our focus from beer to food, and started working with the Spoonacular food API. Losing out on that work wasn’t particularly pleasant, but it did give me some practice with generating functions to perform API queries, so the time wasn’t all wasted. Our final vignette can be viewed in it’s rendered form here and the associated Github repository is here.
The Spoonacular API is full of data on many ingredients and recipes, allowing for searches based on everything from calorie limits, to ingredients, to cuisine categories, to levels of specific micronutrients. One of the things I was interested in looking for was whether other variables seemed to have a relationship with the number of aggregate likes a recipe had. My thoughts were that maybe recipes with more calories would have more likes since they would likely have more fat or sugar to make them tastier, or possibly recipes with higher health scores would get more likes based on a perceived health halo. I was not successful with finding any strong trends there. Most of the recipes had low levels of likes, and then there were a few outliers with many more likes. I may need to look up some of the outliers to try out cooking for myself. Additionally, we saw in our numeric summaries a decrease in average calories when moving from the low to medium to high carb categories. That result was unexpected.
The largest frustrations and difficulties with the project for me were on the technical side of getting Github and R Studio properly connected and rendering output to display properly. Hours were wasted on getting to the point where I could successfully pull down the project repo to R Studio, make changes, commit, and push the updated files to the repo. Those are hours I would have much preferred to have spent working on the meat of the project. The main thing I would change if presented with a similar project in the future is to get started with the technical setup aspects as quickly after the project is assigned as possible. What looks like half an hour of work can turn into a lot more. When I think about the coding portion of the project, the main challenges that I went through were thinking about how I could get from search options that would be easy for a user to work with to the data that I wanted to pull. The logic of pulling the item numbers from an initial query and turning it into one long string of comma separated item numbers that could be used with the “bulk search” option in the API was critical there. Overall, this was an interesting project that I enjoyed during the periods where I wasn’t wildly frustrated with the technology aspects.