Anyone who has worked with any Google API knows how easy most things are for most purposes, but how difficult they can be to be worked-in to a different platform. I’m using this opportunity to take a look at YouTube’s v3 API which has had some recent changes, but requires a rewrite to most applications that use it, since it has made a lot of small lines of code require a complete rewrite, and some some schema, a few extra long functions.

Intro and "The Thing"

The recent change added a new way to access and recieve channel information. Before this change you just need the channel username, but after this change you can use the channel username or the channel ID. The main reason for adding this isn't quite clear to be, because both the username and ID are both unique to a channel, but an ID is infinitely harder to remember, because it is a 24 character randomized string with capital and lower-case lettering, plus integers.

The Issue

The first thing I did to try and wrap my head around this change is to try both the ID and username on https://youtube-collections.com/ and I wasn't surprised when it did not work. The main reason for this is because the GET request features 3 parts: "part", used for requesting a specific part of the result to be sent back to the user, "id", to specify username or (now) ID, and "apikey", for the API key.

The Punchline

This issue renders my website completely useless because it requires user information, completely provided by the user. The information is of unknown origin, and it was easy to guess that the user would input a username because the introduction of the ID, because it was the only thing to provide, just whether it was in URL form (just splitting the URL and finding the appropriate array part) or just a username.

The Inevitable Workaround

Now I have incorporated (hopefully) a standardized fix, which implements before any other in-line functions. What this function, we'll call it Butterfly(), does, is finds if the user's input was a username or ID. To do this it first requests the information like it usually does, using a snippet, an ID and the key, then it asks itself "Is the information I just recieved a whole set of arrays and objects, or was it nothing?". This works because YouTube's API doesn't return data if the input isn't accepted. So then the code assumes the requested information was in the form of an ID instead of a username, and requests the same information, but instead uses the request "part:'id', forusername:id, key:apikey". This should recieve a lot more information, and the information that we want to get, which is the actual username.

Conclusion

It doesn't really matter which order you put these in, but the main difference is that the snippet GET will request far less information, so do this one first to make less of an impact on the user's internet and your overall API token requests. To be clear this will only really work if you are parsing this username down a chain of functions. \For me it was easy to rewrite all the function because it is all very simple GETs, adding to arrays and localstorage.

The Youtube API. It seems like we will be making a move to using only Youtube Videos. In part because that is where almost all of the tutorials are upload anyways, but more importantly because Youtube launched a new API which is incredibly powerful. And by leveraging it we can automate some cool things.