Skip to content
ADVERTISEMENT
Sign In
  • Sections
    • News
    • Advice
    • The Review
  • Topics
    • Data
    • Diversity, Equity, & Inclusion
    • Finance & Operations
    • International
    • Leadership & Governance
    • Teaching & Learning
    • Scholarship & Research
    • Student Success
    • Technology
    • Transitions
    • The Workplace
  • Magazine
    • Current Issue
    • Special Issues
    • Podcast: College Matters from The Chronicle
  • Newsletters
  • Virtual Events
  • Ask Chron
  • Store
    • Featured Products
    • Reports
    • Data
    • Collections
    • Back Issues
  • Jobs
    • Find a Job
    • Post a Job
    • Professional Development
    • Career Resources
    • Virtual Career Fair
  • More
  • Sections
    • News
    • Advice
    • The Review
  • Topics
    • Data
    • Diversity, Equity, & Inclusion
    • Finance & Operations
    • International
    • Leadership & Governance
    • Teaching & Learning
    • Scholarship & Research
    • Student Success
    • Technology
    • Transitions
    • The Workplace
  • Magazine
    • Current Issue
    • Special Issues
    • Podcast: College Matters from The Chronicle
  • Newsletters
  • Virtual Events
  • Ask Chron
  • Store
    • Featured Products
    • Reports
    • Data
    • Collections
    • Back Issues
  • Jobs
    • Find a Job
    • Post a Job
    • Professional Development
    • Career Resources
    • Virtual Career Fair
    Upcoming Events:
    Hands-On Career Preparation
    An AI-Driven Work Force
    Alternative Pathways
Sign In
Profhacker Logo

ProfHacker

Teaching, tech, and productivity.

Working with APIs (part 1)

By Julie Meloni August 31, 2009


Simple API Data Flow

This is the first in a series of ProfHacker 101 posts on working with APIs. Coverage in this post includes an introduction to the concept of the API, why you might want to work with APIs, and what you will need to get started. Posts in the not-too-distant future will include practical examples both of pulling and pushing data from or through an API, and of course handling the results that are returned.


There is no single Application Programming Interface, nor is there a single programming language or method of access through that interface. The developer of a particular application or service purposefully creates a way for users to access the core functional framework or data stored within that service. For example, with Google Maps you can create custom maps including points on the map that contain additional information about the location; with Twitter you can archive search results or even tweet from a custom-built application; with WordPress, plugin developers can create scripts that enhance the underlying framework—the list goes on.

If your request is properly designed according to the API documentation for that application or service, then data will flow back to you through the same doorway. If your request isn’t properly designed, then imagine you’ve sent a scout through the doorway and, finding nothing in the room and, he returned back empty-handed, only to find a note stuffed in his back pocket that says “Hey Request Scout, you didn’t look in the right place. Sorry you missed us. Love, Data.”


So now that you know the concept of working with an API, why might you want to? The reasons for working with an application’s API are as numerous as an application’s users. Using an API you can begin to create a new user experience around the core functionality of the application (operational tasks). Or, you can leverage data already stored to produce reports or create an entirely different application (data manipulation tasks). The possibilities are endless, which probably makes this brief blog post a little maddening—that’s why we planned a series! But even if you think in terms of Twitter, the Twitter API is already in heavy use by developers worldwide.


If you think about the two broad types of tasks I just mentioned—operational tasks and data manipulation tasks—and you are in any way familiar with Twitter, you can begin to see how an API works. Every single Twitter client out there (some of which I’ve discussed before on ProfHacker) that is not the web interface at twitter.com uses the Twitter API. So, if you use TweetDeck or twhirl or Tweetie or whatever the client may be, those are instances in which those application developers have created their own operational tasks (wrapped in nice interfaces) based on the Twitter API and accessing all the data stored by Twitter (your account information, your friends, your followers, etc). Even if the top Twitter client is still the web (at 65%), 35% of all tweets are sent using someone else’s operational tasks built on top of the Twitter API. Similarly, applications that perform data manipulation tasks, such as archiving with Twapper Keeper or seeing real-time search results with Twitter Fall, or looking at Twitter visualizations such as Twistori and Social Collider, are accessing the Twitter API to retrieve that data.


A popular use of an application’s API is the use of the Google Maps API for data manipulation. Using the Google Maps API plus your own or third-party data to create interactive mashups is one of the “gateway drugs” of API scripting, because Google makes it very easy to work with their tools. The Google Maps Mania blog tracks all the Google Maps mashups it can find; here’s a mashup they just discussed about the Station Fire in California. Creating Google Map mashups are a great way to get your students involved in documenting the relationships between events they may be studying and where those events happened in the physical world—not just the world in their books.


How to get started working with APIs completely depends on what you want to achieve. Once you know what you want to do—for instance, do you want to annotate a map, or archive search data, or create a new interface to an existing service, and so on—you can narrow it down to a single application or service whose features or data you wish to leverage. After you determine if you’re going to work with Twitter, or Google Maps, or [insert other application API here], head toward the API documentation for that application or service. All (good) API documentation will have examples for how to complete specific tasks; you have to be able to conceptualize how those tasks fit together.


As far as technical specifications and technical knowledge, it really depends on what you are trying to achieve and with which service’s API. Almost certainly though, you will have to obtain an “API Key” or “Developer’s Key” for the API(s) you want to access. This key is an alphanumeric string that will identify your scripts or your own application when it accesses the parent application’s API. For any of you who are WordPress users, you might already have obtained an API key for WordPress if you have also installed the Akismet or WordPress Stats plugins. The API key is a way to register your installation of those plugins (or your own scripts) with the developers of the platform you are accessing.


Do you need to know a programming language, have a database at your disposal, or otherwise dip your toe into unfamiliar waters? Google Chart APIIt really depends. If you’re working directly with the Twitter API in a meaningful way, then yes you will need to be familiar with a server-side scripting language at least to the extent that I describe in this how-to post regarding archiving tweets. But the Google Developer Resources provide many ways of accessing the various Google APIs without knowing server-side programming. These access methods are based on query strings in a URL (which are themselves accessing the underlying API) and can be used for all sorts of things such as producing the lovely chart you see here.


Working with APIs can be incredibly creative and rewarding in the classroom; they can help your students become more knowledgeable not only about the subject matter they are studying (by working with it in different ways than simply consuming the words in a book) but about the processes through which others are able to feed information to them—and I’m not even mentioning the ways in which documenting APIs can find its way into the technical writing classroom.

In the next installment of this series, I’ll dive into the nitty-gritty of working with two different APIs to pull data—one that requires server-side programming knowledge and one that does not. If you have a particular example you’d like to see, let me know.

To continue reading for FREE, please sign in.

Sign In

Or subscribe now to read with unlimited access for as low as $10/month.

Don’t have an account? Sign up now.

A free account provides you access to a limited number of free articles each month, plus newsletters, job postings, salary data, and exclusive store discounts.

Sign Up



Simple API Data Flow

This is the first in a series of ProfHacker 101 posts on working with APIs. Coverage in this post includes an introduction to the concept of the API, why you might want to work with APIs, and what you will need to get started. Posts in the not-too-distant future will include practical examples both of pulling and pushing data from or through an API, and of course handling the results that are returned.


There is no single Application Programming Interface, nor is there a single programming language or method of access through that interface. The developer of a particular application or service purposefully creates a way for users to access the core functional framework or data stored within that service. For example, with Google Maps you can create custom maps including points on the map that contain additional information about the location; with Twitter you can archive search results or even tweet from a custom-built application; with WordPress, plugin developers can create scripts that enhance the underlying framework—the list goes on.

If your request is properly designed according to the API documentation for that application or service, then data will flow back to you through the same doorway. If your request isn’t properly designed, then imagine you’ve sent a scout through the doorway and, finding nothing in the room and, he returned back empty-handed, only to find a note stuffed in his back pocket that says “Hey Request Scout, you didn’t look in the right place. Sorry you missed us. Love, Data.”


So now that you know the concept of working with an API, why might you want to? The reasons for working with an application’s API are as numerous as an application’s users. Using an API you can begin to create a new user experience around the core functionality of the application (operational tasks). Or, you can leverage data already stored to produce reports or create an entirely different application (data manipulation tasks). The possibilities are endless, which probably makes this brief blog post a little maddening—that’s why we planned a series! But even if you think in terms of Twitter, the Twitter API is already in heavy use by developers worldwide.


If you think about the two broad types of tasks I just mentioned—operational tasks and data manipulation tasks—and you are in any way familiar with Twitter, you can begin to see how an API works. Every single Twitter client out there (some of which I’ve discussed before on ProfHacker) that is not the web interface at twitter.com uses the Twitter API. So, if you use TweetDeck or twhirl or Tweetie or whatever the client may be, those are instances in which those application developers have created their own operational tasks (wrapped in nice interfaces) based on the Twitter API and accessing all the data stored by Twitter (your account information, your friends, your followers, etc). Even if the top Twitter client is still the web (at 65%), 35% of all tweets are sent using someone else’s operational tasks built on top of the Twitter API. Similarly, applications that perform data manipulation tasks, such as archiving with Twapper Keeper or seeing real-time search results with Twitter Fall, or looking at Twitter visualizations such as Twistori and Social Collider, are accessing the Twitter API to retrieve that data.


A popular use of an application’s API is the use of the Google Maps API for data manipulation. Using the Google Maps API plus your own or third-party data to create interactive mashups is one of the “gateway drugs” of API scripting, because Google makes it very easy to work with their tools. The Google Maps Mania blog tracks all the Google Maps mashups it can find; here’s a mashup they just discussed about the Station Fire in California. Creating Google Map mashups are a great way to get your students involved in documenting the relationships between events they may be studying and where those events happened in the physical world—not just the world in their books.


How to get started working with APIs completely depends on what you want to achieve. Once you know what you want to do—for instance, do you want to annotate a map, or archive search data, or create a new interface to an existing service, and so on—you can narrow it down to a single application or service whose features or data you wish to leverage. After you determine if you’re going to work with Twitter, or Google Maps, or [insert other application API here], head toward the API documentation for that application or service. All (good) API documentation will have examples for how to complete specific tasks; you have to be able to conceptualize how those tasks fit together.


As far as technical specifications and technical knowledge, it really depends on what you are trying to achieve and with which service’s API. Almost certainly though, you will have to obtain an “API Key” or “Developer’s Key” for the API(s) you want to access. This key is an alphanumeric string that will identify your scripts or your own application when it accesses the parent application’s API. For any of you who are WordPress users, you might already have obtained an API key for WordPress if you have also installed the Akismet or WordPress Stats plugins. The API key is a way to register your installation of those plugins (or your own scripts) with the developers of the platform you are accessing.


Do you need to know a programming language, have a database at your disposal, or otherwise dip your toe into unfamiliar waters? Google Chart APIIt really depends. If you’re working directly with the Twitter API in a meaningful way, then yes you will need to be familiar with a server-side scripting language at least to the extent that I describe in this how-to post regarding archiving tweets. But the Google Developer Resources provide many ways of accessing the various Google APIs without knowing server-side programming. These access methods are based on query strings in a URL (which are themselves accessing the underlying API) and can be used for all sorts of things such as producing the lovely chart you see here.


Working with APIs can be incredibly creative and rewarding in the classroom; they can help your students become more knowledgeable not only about the subject matter they are studying (by working with it in different ways than simply consuming the words in a book) but about the processes through which others are able to feed information to them—and I’m not even mentioning the ways in which documenting APIs can find its way into the technical writing classroom.

In the next installment of this series, I’ll dive into the nitty-gritty of working with two different APIs to pull data—one that requires server-side programming knowledge and one that does not. If you have a particular example you’d like to see, let me know.

We welcome your thoughts and questions about this article. Please email the editors or submit a letter for publication.
Share
  • Twitter
  • LinkedIn
  • Facebook
  • Email
ADVERTISEMENT
ADVERTISEMENT

More News

Marva Johnson is set to take the helm of Florida A&M University this summer.
Leadership & governance
‘Surprising': A DeSantis-Backed Lobbyist Is Tapped to Lead Florida A&M
Students and community members protest outside of Coffman Memorial Union at the University of Minnesota in Minneapolis, on Tuesday, April 23, 2024.
Campus Activism
One Year After the Encampments, Campuses Are Quieter and Quicker to Stop Protests
Hoover-NBERValue-0516 002 B
Diminishing Returns
Why the College Premium Is Shrinking for Low-Income Students
Harvard University
'Deeply Unsettling'
Harvard’s Battle With Trump Escalates as Research Money Is Suddenly Canceled

From The Review

Illustration showing a valedictorian speaker who's tassel is a vintage microphone
The Review | Opinion
A Graduation Speaker Gets Canceled
By Corey Robin
Illustration showing a stack of coins and a university building falling over
The Review | Opinion
Here’s What Congress’s Endowment-Tax Plan Might Cost Your College
By Phillip Levine
Photo-based illustration of a college building under an upside down baby crib
The Review | Opinion
Colleges Must Stop Infantilizing Everyone
By Gregory Conti

Upcoming Events

Ascendium_06-10-25_Plain.png
Views on College and Alternative Pathways
Coursera_06-17-25_Plain.png
AI and Microcredentials
  • Explore Content
    • Latest News
    • Newsletters
    • Letters
    • Free Reports and Guides
    • Professional Development
    • Virtual Events
    • Chronicle Store
    • Chronicle Intelligence
    • Jobs in Higher Education
    • Post a Job
  • Know The Chronicle
    • About Us
    • Vision, Mission, Values
    • DEI at The Chronicle
    • Write for Us
    • Work at The Chronicle
    • Our Reporting Process
    • Advertise With Us
    • Brand Studio
    • Accessibility Statement
  • Account and Access
    • Manage Your Account
    • Manage Newsletters
    • Individual Subscriptions
    • Group and Institutional Access
    • Subscription & Account FAQ
  • Get Support
    • Contact Us
    • Reprints & Permissions
    • User Agreement
    • Terms and Conditions
    • Privacy Policy
    • California Privacy Policy
    • Do Not Sell My Personal Information
1255 23rd Street, N.W. Washington, D.C. 20037
© 2025 The Chronicle of Higher Education
The Chronicle of Higher Education is academe’s most trusted resource for independent journalism, career development, and forward-looking intelligence. Our readers lead, teach, learn, and innovate with insights from The Chronicle.
Follow Us
  • twitter
  • instagram
  • youtube
  • facebook
  • linkedin