Do you want two systems to talk to each other? To share data with the community you support? To build a mobile application with volunteers? Then APIs are for you.
What does an API do?
An API, short for Application Programming Interface, lets systems talk to each other. Some APIs are called Web Services because they talk via the Internet.
APIs are like data ambassadors. Each program (or person) has their own stuff going on. Sometimes one side wants something from the other. It could be asking a question or doing some kind of task. One side sends a request, or call, using the API. The other side listens, then hands the API back a response. There is no direct link between the two programs. Instead, the API carries messages back and forth.
Check out this explanation if you’d like to learn more: APIs: How the Internet Works Behind the Scenes. Want to take a deeper dive? Explore this series of articles: What are APIs and How Do They Work?
Why should I care about APIs?
APIs help others connect with data for their own projects. Users can mix and match data from multiple sources to design apps, create interactive web experiences, and identify unexplored data trends. Want some inspiration? Here’s a list of heritage sites doing interesting things with APIs: Cool Stuff Made with Cultural Heritage APIs.
With APIs we gain flexibility. People who want to work with data don’t have to consult with the original vendor or know the entirety of a program’s code. Instead, they use the API to go directly to what they want.
APIs also help with security. While there is a conversation between both sides, the API works in the middle. The API controls what we see and do, limiting system exposure. Each API determines how much data is shared and what actions are allowed. Some APIs provide read-only access. Others support deeper integration with insert, update, and delete privileges.
How do APIs communicate?
APIs communicate using different rules and conventions. Some are more formal than others. SOAP (Simple Object Access Protocol) is extremely structured. XML-RPC (Remote Procedure Call) is less complex. REST (Representational State Transfer) is more lightweight. Depending on the method used, most requests and responses are in XML or JSON. If you’d like to better understand the difference between models, try slides 11 – 33 of this presentation: Webservices Overview: XML RPC, SOAP and REST. For a shorter summary, this infographic features a comparison: REST vs SOAP.
Where do I get an API?
APIs can be public or private. Public APIs are available for anyone’s use. If you’re looking to experiment, ProgrammableWeb maintains a directory of over 18,000 public APIs for all kinds of services. System integrators, adventurous data scientists, and curious end-users can connect to data with any of them. Some public APIs may have Terms of Service. Beyond defining the scope of actions and data available, there are few, if any, additional restrictions. Documentation for public Axiell APIs is available here: Adlib, IMu. Information about the Calm API is available via email@example.com. APIs for Mimsy XG and Micromusée are expected in 2018.
A private API restricts communication to specific users / systems. Typically used internally by an organisation’s own developers, private APIs are not open or shared.
If you’d like to learn more about the differences between Public and Private APIs, check out this article: https://www.upwork.com/hiring/development/public-apis-vs-private-apis-whats-the-difference/
This post is the first in a series about technology that we’re using at Axiell. Be on the lookout for our next post about how databases store information. Have something you’d like us to address? Email your suggestions to firstname.lastname@example.org.