Building My First Ruby CLI Gem and Un-Paginating an API

Roughly a month and a half into my Software Engineering program at Flatiron, my classmates and I encountered our very first project of the course: building a Ruby gem that provides a CLI (Command Line Interface) to an external data source. Essentially, we were to choose an API (Application Programming Interface) of our own choice, extract data from it, and create a gem that would allow the user to interact with said data.

As Project Week was nearing closer and closer, my panic increased accordingly. “Which API do I choose?” “Oh my god, what if my code sucks?” “Can I do it? Oh my god. I can’t do it.” With my imposter syndrome still deeply rooted in me, I was feeling a wide variety of emotions, from excitement to sheer dread.

The main point of the project was to code a program that allows the user to go one level deep, with “level” referring to the user being able to make a choice and then get back information based on that choice. However, I wanted to make my project even more interactive and fun. Therefore, with the idea of RPG/“choose your adventure” interactive games in mind, I decided to base my project off of a Rick and Morty API.

Rick (left) and Morty (right) are the titular characters of the show “Rick and Morty”

Being a fan of adult cartoons, especially Rick and Morty, I wanted to incorporate my interests into the project and really show my personality through it. I knew that if I went with the Rick and Morty API, I’d have access to hundreds of characters, and therefore be able to create that interactive gem I had in mind.

Soon after I decided on the API, I encountered an obstacle: it was paginated. My cohort did not discuss paginated APIs, nor did I know it was a thing. After reading multiple articles on it, I started to internally panic once again as I was now unsure of how to go about my project. Do I only base it off of the first page, which only included 20 characters? Do I abandon this API, along with the flow chart I created (albeit messily drawn in my notebook) and all the lofty ideas I had planned for it? Or should I find a way around it, despite the extra challenge?

I had already sunken hours into looking through different APIs and the idea of facing defeat without even trying didn’t sit right with me. Therefore, rather than run away from the challenge, I decided to face it head on.

While there were articles and Stack Overflow threads that provided solutions for paginated APIs, I didn’t recognize the methods they used, so I decided not to use them. I firmly wanted to only use code I was familiar with, especially since I’d have to explain it in detail later during my project review meeting.

The Rick and Morty API had 34 pages and 671 characters in total (as of April 2021), with 20 characters, or objects, on each page. I had the ambitious goal of wanting to access all 671 characters.

After multiple hours of playing around with my code and sending it through Pry, I finally decided to have the API run through REST Client twice. Mhm, you heard me right.

I wanted to keep my code as flexible as possible. Rather than hard code my program into telling it that the API had only 34 pages by setting a variable to the number 34, I wanted my program to grab the number of pages from the API itself each time it ran. Therefore, the first time was to grab the number of the API’s total pages, which I then shoveled in all 34 of their URLs into an empty array, so that the second time I ran it through REST Client was to iterate through that array to again shovel in each page’s data to another empty array. Afterwards, I used .flatten to flatten the end resulting array, since it essentially now was an array inside another array.

I understand the above word vomit may be a bit difficult to understand through English, so let’s try to use Ruby to explain my logic.

First time I ran the API through REST Client

As you can see above, I ran the API’s URL through REST Client on line 5 and then parsed it with JSON on line 6 for readability. Afterwards, I took the API’s total number of pages, which was accessible within the "pages" key inside the "info" hash and set it equal to a variable called total_pages. This did the job of keeping my code flexible and always up-to-date, in the case that the API grew larger, thus having more pages.

The next obstacle was to have the program iterate through each page, so it could check for a Rick and Morty character if/when called. So, I had a variable called page_number set to 0 and used an until loop. As page_number incremented by 1 each time, all the URLs of the API’s pages would be added into an empty array called all_pages until it reached total_pages, or 34, the total number of pages in the Rick and Morty API.

Second time

Now, this brings us to the second time I ran REST Client. I wanted one big array for my CLI class to access. Therefore, I iterated through the all_pages array, running each page through REST Client, parsed it with JSON, specifically only grabbing the "results" hash, which contained all the information I needed from the API, and finally shoveled all those pages into another array called all_data . Like I said before, this ultimately resulted in an array inside an array, so I flattened all_data into one array with .flatten and set it equal to a variable called characters, so I could easily access it.

With all this done and behind me, the next immediate step was to simply iterate through characters and initialize the objects, so I could begin writing my Character class.


This was undoubtedly the most difficult process of my project since I had to figure out a way around this challenge all on my own. The rest of my project was comparably easier, especially since I had pseudocoded it out during the planning stage. While I may have overcomplicated it by running REST Client twice and creating two arrays, only to flatten it in the end, I believe that this was one of the better methods, especially with my current knowledge on programming.

Ultimately, I had so much fun doing and learning from this project. Despite the hours and emotions I poured into creating this gem for four days, one thing I most definitely gained from it was the enduring confidence that I can indeed overcome any programming obstacles that come my way. What an immeasurable feeling! Conclusively, as Rick best puts it:

I’m a recent graduate from Carnegie Mellon University with a business degree, currently attending Flatiron School for Software Engineering!