Gotta Catch ’Em All: Building a CLI ‘Pokédex’ using the Poke API
The thought of creating my own CLI application only 3 weeks into my coding bootcamp program was daunting at first. However, after copious amounts of coffee, a few late nights coding, and lots of review of my program notes, I finally have a CLI project that I’m happy to share here.
For my CLI project, I built a Pokédex that allows the user to see the full list of the original 151 Pokémon and look them up by name and index number. After the user makes a choice, the program returns detailed information for that particular Pokémon. I also added a “choose your own adventure” story element to make the project a bit more interesting.
If you’re like me, a 90s kid, then you probably grew up collecting Pokémon cards, or watching the Saturday morning cartoons, or playing the video games. Maybe all of the above. When it came to choosing an API for my project, it was an easy decision to go with the Poke API.
Choosing an API
First question, though — what exactly is an API? Two weeks ago, I was not familiar with this computing term. API stands for application programming interface. Essentially, an API is the way a company or organization exposes and shares their data and/or functionally with the public.
The other important term to understand is “endpoint”. An endpoint refers to the URL that we use to request the desired data from the API. When navigating an API’s documentation, it is helpful to pay close attention to the endpoints and explore them in order to figure out what is included in the dataset and how it’s organized.
One key takeaway for me during this project was the importance of due diligence when choosing the right API. While this point came up in my coding bootcamp lectures, I did not fully appreciate the wisdom of this advice until I started working with the Poke API.
Even though I ultimately spent a lot of time researching different APIs for my project, I kept coming back to the Poke API as my favorite one. I quickly discovered that there was no perfect API out there. I knew that in order to create a successful project I would need to choose an API that I found interesting. Thus, I chose the Poke API and committed to the idea that I would make it work.
The Poke API (Read the documentation)
During the exploration phase of my project, I quickly learned that the Poke API is notoriously finicky to use. The API is composed of multiple nested hashes and oftentimes the values of the keys in the hashes point to URLs.
While I did appreciate the Poke API’s extensive amount of information, to be honest, reading through the documentation was overwhelming at first. Although the massive amount of data stored in the Poke API was initially challenging to sift through, I took my time exploring the documentation and various endpoints.
This exercise helped me figure out how certain endpoints communicated with one another (or didn’t) and how the dataset was organized. Even though the API structure did not feel navigable at first, there was indeed a logic and method to how the data was organized, and understanding the documentation ultimately helped me make better coding decisions.
Making the Call
Let’s say you’ve chosen your API. Well, now it’s time to make the request call.
At the most basic level, making an HTTP request in Ruby, involves pulling the API request via an endpoint and correctly parsing out the dataset in your code editor.
I used the following method to request my initial Pokédex API dataset:
If at first you don’t succeed, pry pry again…
Another important consideration is testing out all the endpoints, especially if you’re planning to make the API request call using string interpolation within your URL endpoint. This exercise helped solidify my knowledge of pulling requests and was a good check to make sure the API endpoint would work before using it.
This is where the pry method saved the day. What is pry you ask? Pry is a Ruby gem that allows you to essentially “freeze” your program at a given spot so that you can look inside your code to figure out what’s working or not.
Since I was making API requests for the first time, I inevitably made mistakes. Pry helped me debug and more importantly gave me a fuller understanding of how my HTTP get request was communicating with the rest of my code.
Final Takeaways
Ultimately, the data I wanted for my Pokédex was spread out across 3 different endpoints in the Poke API. As a result, I ended up making three separate HTTP requests. Although this was initially challenging, once I successfully found the right endpoints for my project and carefully read through the API documentation, it became a lot clearer on how to effectively utilize the dataset and incorporate it within my CLI code. Halfway into my project, I realized that choosing the right endpoints was the better approach for successfully building a CLI project rather than trying to overcomplicate my code by relying on a lackluster endpoint.
One of my favorite things about this project was that I learned firsthand that in coding you can usually find a workaround to a tricky problem, even if you might not have all the answers or coding expertise as a new developer. This type of thinking and resourcefulness can definitely be handy when you feel like you’ve hit a wall or come across a new issue. As a beginner, information overload can definitely be a real struggle, so the next time you encounter a complicated API take a step back, read the documentation carefully and earnestly, befriend “pry”, and embrace debugging!
