Lesson Weekend

We've already accomplished so much today! And you know what's even better? We haven't even gotten to the coolest part yet! In this lesson we'll begin addressing the main focus of today's workshop: APIs. We'll discuss what they are, what purpose they serve, and why they're such a big deal. Then, we'll begin coding our project to interact with an API.

Introducing APIs

The term API stands for "Application Programming Interface". More buzzwords and jargon, we know. But in basic terms, APIs just allow applications to communicate with one another. That's it.

There are two general types of interactions API-using apps and sites have:

  1. They allow us to go get data from outside sources. We can send an API a request detailing the information we want. The API's server will respond with data (or, an error if something went wrong).

  2. APIs allow our sites to alter data on other applications, too. For instance, you've probably seen "Share on Facebook" or "Share on Twitter" buttons on miscellaneous websites. This is an example of an API! When/if you click one of these buttons, the site you're visiting can communicate with your Facebook or Twitter account, and alter its data by adding new status or tweet. (Although, obviously you need to give it permission to do this!)

The application we're building will only use the first type of interaction. We'll program our site to automatically reach out and grab information from the Act-W API to display on our page.

Benefits of APIs

But, if this API thing is actually fairly straightforward, what's all the hubbub about anyway? Why is this such a big deal? Let's demonstrate.

Okay. So. Right now in this very workshop we're creating an application that will list (anonymized) information about awesome ACT-W attendees, right? And an API is going to to provide us this information, yeah? Well, let's imagine for a moment that we don't have this API, but we each still want to achieve the same goal: Write a website that lists all Act-W attendees. How would we go about that? Everyone's approach would differ. But we can generally assume everyone would need to complete following types of steps:

  • We would need to exit the doors of this classroom, find an Act-W organizer, ask them for a list of attendees, and wait however long it took them to locate and provide us this list.

  • Then, we would all need to take turns reading that list, and typing each attendee's (anonymized) info directly into our program. Our HTML would start looking like this:

...
<div class="well attendee-entry">
  <b>Age Range: </b>26 - 35<br>
  <b>Job Category: </b>Manager<br>
  <b>Gender: </b>Trans<br>
  <b>Ethnicity: </b>Other<br>
</div>  
<div class="well attendee-entry">
  <b>Age Range: </b>26 - 35<br>
  <b>Job Category: </b>HR/Recruiting<br>
  <b>Gender: </b>Female<br>
  <b>Ethnicity: </b>Caucasian<br>
</div>  
<div class="well attendee-entry">
  <b>Age Range: </b>18-25<br>
  <b>Job Category: </b>Programmer/Engineer/Developer<br>
  <b>Gender: </b>Female<br>
  <b>Ethnicity: </b>Asian<br>
</div>  
<div class="well attendee-entry">
  <b>Age Range: </b>>45<br>
  <b>Job Category: </b>Executive/Owner<br>
  <b>Gender: </b>Prefer not to answer<br>
  <b>Ethnicity: </b>Other<br>
</div>
...

(Note: When you see an ellipses (...) in a code snippet, as seen above, it means we've omitted portions of a file for demonstration purposes, so we can hone in on a specific area.)

And that's only the first four attendees in the code above. Have you seen this conference? There's way more of us than that...

  • Then, after we all manually typed each attendee's entry into our individual applications...imagine if something changed. What if there were late registrations, or someone's info was incorrect, and Act-W had to update their records to correct the error. Assuming we all still wanted our applications to remain 100% accurate, we'd all have to go back into our applications' code again and manually make these changes.

Seems more like an exercise in typing than coding, right?! That doesn't seem efficient at all.

However, by completing this same task with an API, we reap the following benefits:

  • We don't have to hard-code every piece of information we want to display right into our application. No typing. No copying. We rely on the API to provide this info. We only need to tell our application how to request info from the API, then tell it what to do with the info when it is returned.

  • When changes occur, only the API itself needs to be updated. Then, all applications that request data from it will automatically receive the new updated data. We won't all have to manually update our lists!

Can you see how much time this saves us? This seems like a pretty good deal, right?

What Does an API "Look" Like?

Okay, so we know how we can benefit from APIs. But that still doesn't answer a remaining question: What is an API anyway? What does it look like? We know it has data, and it's floating out there online...but...what is this illustrious thing?

Well, in our case, it's just a pile of data hosted online. Check it out. You can preview the Act-W API by clicking on this link. As you can see, it's just a big pile of information online.

Now, do note that many APIs are more complex than this. Some require our programs to include special credentials in order to access data (especially if the API contains sensitive information). And others offer more than just read-only text-based data. (Remember, APIs like Twitter or Facebook actually allow a program to post to someone's account). But, essentially, APIs are just big piles of data and other functionality that our programs can communicate (or "interface") with.

Pretty cool, right?

Now that we understand what APIs are for, what they look like, and how our programs can benefit from them, we'll begin coding our own app to make a successful API request in the next lesson!