This vendor-written piece has been edited by Executive Networks Media to eliminate product promotion, but readers should note it will likely favour the submitter's approach.
You might have figured out that yes, I'm one of those people playing Pokémon Go. Or, as is often the case of late, not playing Pokémon Go. That's bad, because it also means our youngest is not playing, because as it turns out we're both using Pokémon Trainer Club (PTC) accounts to play, not Google accounts, and we can't get in.
That's significant, because while the two of us are frustrated by our inability to "authenticate" and login to play, my husband chose to use his Google account and, well, he's not having the same issues.
Which got me digging into some technical concerns that should really resonate with every company, regardless of the app they're launching. That concern revolves around the new AAA - APIs, Authentication, and Availability.
Interestingly, this quest began when I was reading an article in Forbes about tracking Pokémon in Pokémon Go. In any case, that led to another article and another, with one speculating that the reason tracking was (at least initially) broken was due to a game update in which an API key was inadvertently left out of the tracking calls back to Niantic's servers.
Whether this is the case or not, such a faux pas would, indeed, break APIs. But the thing I kept coming back to was that if I couldn't login to my PTC account and play, why was it that I could switch to my Google account and get in easily?
The API-Authentication Connection
Just about every API call in those repositories handles the same exception: LoginFailedException. In other words, even a simple call to find nearby Pokémon may result in a LoginFailedException.
Which is really not all that surprising. See, monolithic web applications often track authenticated users via sessions, which often means a cookie that contains a session ID or some other token that the application checks before actually doing anything else (that's a stateful architecture). APIs aren't that much different, in that each API call has to have a way to ensure the calling application (the user) is actually authorised to make the call in the first place. They have to be "logged in".
Now, APIs often use API keys to achieve this. The key is generally checked against a user profile to ensure the call is authorised. Every call (in a stateless architecture). There are various reasons for such a decision, including the ability to rate-limit calls. Which is a big deal. Apigee's State of APIs 2016 report noted that 68 percent of APIs were taking advantage of quota management (which is also known as rate limiting, metering, etc....) In order to do that technical trick, one has to first know how many calls have been made in the past minute/hour/day, and thus it must be tracked somewhere safe (so users can't manipulate it and trick the application into allowing more calls per time period).
Sign up for CIO Asia eNewsletters.