Introduction to APIs

This is the script for a presentation given to Professor Benn Kosynski’s Appcology class at the Emory Goizetta Business School.

The tech industry has been experiencing a lot of containerization over the past decade. Where large dev teams used to collaborate on giant programs, writing code together and then handing it off to someone to publish and deploy, increasingly, as the projects got bigger and bigger, programmers would split the project into smaller self-contained pieces, and work on those in smaller teams. Instead of handing off code for the entire project at once to deploy, its becoming more common for these individual teams to submit virtual computers at their own pace. These are already running the apps that specific project needs, ready to be deployed wherever. This all really highlights how separated a single product can get. All these tiny individual apps are then able to talk to one another to deliver a cohesive product to the end user.

For any modern tech service, this strategy is indispensable. Its often called ‘microservice architecture’, where tons of small services interact with one another, forming one cohesive app.

This is a diagram taken from a Netflix engineer’s talk about microservices at Netflix. Each of these points is an individual app, responsible for an individual piece of the Netflix puzzle, and theres a large amount of communication between them. Believe it or not, this is only the explanation of their solution for a specific subset of the things they provide — not all of Netflix.

So even though this microservice architecture is used a lot in giant companies working on a single product, its also very common for these companies to offer a way for other services to interact with their platform. In this way, even though the Netflix ecosystem is pretty big on the inside, theres a gateway other apps can access and pretend that Netflix is it’s own tiny microservice. Even though Netflix is pretty big itself. This will become more clear after the demo, but it’s actually visible in the diagram I showed

There are a bunch of cool reasons why microservices are practical and a bunch of cool ways to make the process of creating these simple. For now however I want to hone in on a specific aspect: the way these guys communicate between each other. APIs

API is short for application programming interface. This is basically a protocol that services use to communicate over a network, like the internet. These can actually vary a lot as well, but we’re going to hone in on the most common type of API, a REST API. This type is incredibly useful because it allows us to ask an application about it’s current state, and then change it if we want to. Its also incredibly easy to start with; by browsing the web, you’re actually interacting with a REST API. The servers that store websites and host files are actually responding to REST API requests. So, we can easily send requests to our app with just a web browser.

I’ve actually gone ahead and created a custom API for us to play with, in Python.

from flask import Flask
messages = []
app = Flask('FlaskApp')
@app.route('/')
def get_messages():
    return '<p>'.join(messages)
@app.route('/<text>')
def post_message(text):
    global messages
    if text == 'favicon.ico':
        return ''
    messages += [text]
    return get_messages()
app.run(host='0.0.0.0', port='8080')

Those of you who can understand python should be able to see that we’re doing something funny with that messages array variable at the top. This is actually a chat application. It’s very simple, but it performs the duties that we need.

This is actually defining two routes… or URLs, for your browser. I actually went ahead to host this on a Linode cloud server at 45.56.109.245. To access this chat app, you should open your browser and go to the website: http://45.56.109.245. There, you’ll find a list of messages posted by other users. If you click on your url bar, and add a slash and then a short message after the url, you’ll post your own message. For example, going to the url http://45.56.109.245/hello will post the message “hello” publicly, for everybody else to see.

Feel free to check that out. The server is going to be live for another week, so it isn’t permanent permanent, but keep in mind that everything you post there is visible to the rest of the class until I take it down.

Of course, it’s very possible to also query stuff from other APIs with python, and this is much more common and fun to do. Lots of different services have public APIs, such as Google, Netflix, Amazon. A few companies have been built around the idea of providing a paid API, such as the recently IPO’d company Twilio, which provides an API for easy access to phone numbers. Using a variety of APIs like this, a Python script can link together multiple different services to create something completely new and very powerful. This is the way you can interact with actual services that everybody uses, and to create impactful code.

To demo this, gonna write a quick ‘client application’ that’s going to basically be an interface for the API that we already have.

import requests
API_ENDPOINT = 'http://45.56.109.245/'
def post_message(m):
    response = requests.get(API_ENDPOINT + m)
    messages = response.text.split('<p>')
    print('\033c')
    print('\n'.join(messages))
while True:
    post_message(input(": "))

There is also a very famous no-code tool allowing us to utilize APIs: IFTTT. Creating a If This Then That recipe has been one of your first homework assignments in this class — what that service actually does, behind the graphics, is utilize the public APIs of so many different companies, allowing you to treat them like ‘microservices’, and letting you link them together in thousands of different ways. You should be fairly familiar with how that works.

APIs allow us to turn the full spectrum of modern software into individual building blocks, that we can then interact with and connect either programmatically, with Python and requests, or increasingly using graphical services like IFTTT.