A Tale of Two APIs

How I built a Frankenstein’s monster from data

looks pretty software engineery, right?

Hi there! If you’ve read any of my previous articles, you may know that I’m a software engineering student in Flatiron School’s coding bootcamp. Over the course of the program, students are required to complete five projects. In the process of working on my Mod 4 project, I had an interesting experience working with apis. I’d like to share some of that experience here.

For our project, my partner and I decided to make an app that would require us to fetch data about a lot of movies. If you’ve ever built an app that requires an external api, you probably know how frustrating it can be to choose the right one. And for something as common as movies, there are lots to choose from! Our project specifically dealt with moves that are available on Netflix. For several years now, Netflix hasn’t offered an API of their own, but there are many others available online.

When choosing an API to use with your app, you need to consider a few things, such as:

• the cost of the API
• how many calls you’re going to be making
• whether you’ll be calling the API on the frontend or the backend
• the format of the returned data

After some deliberation, we decided to go with uNoGSNG, an unofficial Netflix API. We accessed the data through RapidAPI, a marketplace for browsing and testing many free and paid APIs.

RapidAPI is a useful site for browsing and testing a wide variety of APIs

After some testing, it looked like uNoGS would provide us with good data, but it was missing certain important information like data bout the cast, crew, and plot. However, we didn’t want to jump ship because it seemed like the best API for Netflix-specific data on our budget. To learn more about the API, we visited the developer website, https://unogs.com/. Instead of finding documentation, however, we found a user interface for the API!

pretty nifty!

It’s a pretty straightforward interface, laying out its features and endpoints in a visually-appealing way. You search for, say, Nightcrawler, and this is the result:

nice

However, when you click the movie div, you’re presented with information not available from the uNoGS API itself:

Where’d all this data come from??

Despite having seemingly no data about cast and crew, the uNoGS site is giving us valuable IMDB information! I found that to be pretty odd, so I did some digging in the site’s source code. (To do this, right click on a page and click “View Page Source.” You could also right click on an element, click “Inspect,” and then go poking around in the Sources tab.)

And after a little digging, I found it: evidence that this API was serving up data from another API!

looking for a needle in a haystack

It turned out that uNoGs was making a call to omdb, a popular API for searching movie data. I couldn’t believe my eyes! I felt like I had gone to a restaurant where half the menu was just…food from another menu!? But then I got to thinking — what if I, too, could present my users with all this information?

Through a lot of boring enumeration that I won’t get into here, I figured out a way to make the most of both of these APIs. I’m working in React, so in componentDidMount , I made a fetch request to the uNoGS api using a string of genre IDs I retrieved from their /genres endpoint. I saved the data I received from the API in an array in state and then called another function, createMovieObjects() , and passed in that data:

I use the Synthwave ’84 extension for these cool colors

The createMovieObjects function takes in an array and maps through it:

createMovieObjects = (moviesArr) => {
    let apiKey = [API KEY]
    let newArray = moviesArr.map(movie => {
    this.omdbRequest(movie, apiKey)
    })
}

And this is where the fun really starts. In omdbRequest() , I called the omdb API using the imdbidproperty from each movie object in the uNoGS array.(Looking back, it should’ve been a sign that uNoGS was serving up IMDB IDs in the first place!) I then saved that omdb data in state and use it to create a comprehensive movie object containing information from both APIs:

neato!

After that, it was just a matter of saving those objects into an array in state called frankensteinMoviesArray . And once they were saved, they were just like any other Javascript object, full of data to use in my app! Honestly, this was one of the most fun coding experiences I’ve had so far. I felt like a detective going through the uNoGS source code, searching for evidence and retracing steps. And I learned a lot about APIs, manipulating data, and making fetch requests as agile as possible.

Thanks for reading, and happy trails in your own coding adventures!

Sources:

• Tech Crunch
• RapidApi