Reworking My API 101 Content: Consuming APIs
16 Oct 2014
APIs came in to existence to satisfy a demand for access to valuable content, data and resources, and the more APis that are developed, the more the appetite for API consumption has grown. APIs enable website, web and mobile applications to build applications, using resources that were completely out of reach in even the recent past. Some API resources, like a simple city look-up by postal code, might be simple enough that a developer could recreate, but other resources such as global satellite imagery is something the average developer does not have the resources, or the time to create—the more API resources available, the cooler the apps we build, and the more we hunger for valuable API resources grows.
Starts with a Need
API consumers rarely want to use an API, just to learn about APIs, they have a need, a problem they need to solve. They want to provide a feature in their website, or mobile application. Often times people just want two systems to talk to each other, or be able to analyze and visualize information in a particular way, to accomplish a business or personal objective.
Discovering The APIs You Need
The API savvy technologists are aware of the vast wealth of APis available today, and know to Google for the API they need, visit API directories like ProgrammableWeb or Mashape, and emerging API search engines like APIs.io.
Before you can unlock the value of an API, you need to understand how common authentication patterns work for any API. Some API providers use basic authentication, which is baked into HTTP, while others use application or developer keys to be able to talk with APIs. oAuth is fast becoming default for API providers who serve up private users information, allowing platforms to manage identity and access in a way that gives control over to end-users of applications built on top of APIs. Many providers are also using SSL as default for all API communication, protecting API consumption.
Actual integration between applications and APIs, is ultimately up to API consumers, but API providers and a growing number of API tools and services, are making API integrations easier, and often automated. Most web API resources can be accessed via a simple URL, something anyone, with a basic amount of web knowledge, can integrate API resources into their world.
There are plenty of API projects to be had for fun and hobby, but for any project to be sustainable it must generate revenue and be able to sustain itself. There several proven approaches to generating revenue around API integration including application sales, providing premium features, selling content or subscription to the content, advertising, in-app payments, affiliate links, data generation, and through partnership. Of course there is always the independently funded efforts, which make things easier.
Software as a Service (SaaS)
The primary motivation for API integration is to provide access to data, content, and other resources available in online Software as a Service (SaaS) platforms. Services like Evernote for notes, Pinboard for links, Flickr for photos, and Youtube for videos, all use APIs to enable integration with other applications, as well as basic data portability for software users.
Platform as a Service (PaaS)
Like SaaS, its cousin Platform as a Service (PaaS) employ APIs to enable application providers, developers, and hackers with the ability for rapidly deploy applications ranging from Wordpress, to ElasticSearch. Usually if an application is running on PaaS platforms like Heroku, or Google Apps Engine, there is a set of APIs for configuring, monitoring and managing most aspects of the app.
Infrastructure as a Service (IaaS)
The savviest of IT Operations have moved to the cloud, and run all of their infrastructure using Infrastructure as a Service (IaaS) providers like Amazon Web Services for everything from server capacity, and storage to DNS and content delivery networks (CDN). Every piece of IT infrastructure that runs in the cloud has an API or CLI interface for it, allowing the management of all IaaS infrastructure programmatically.
Backend as a Service (BaaS)
As if we needed another acronym, but here we go, Backend as a Service (BaaS) is an approach for providing web and mobile app developers with a way to connect their applications to backend cloud storage and processing while also providing common features such as user management, push notifications, social networking integration, and other features that mobile users demand from their apps these days. As approaches to API deployment evolve, we are seeing more API deployment platforms emerge that very much resemble earlier goals of BaaS, allowing for the agile deployment, and consumption of valuable resources, via BaaS platform APIs.
The popularity of platforms like Twitter and Facebook owe a great deal of their buzz to the fact that there were embeddable buttons, badges, and widgets, allowing for the sharing, syndication, and engagement with their platform using API driven, embeddable tools. The ability to copy and paste a little bit of code, maybe configure a few settings, and be able to publish data, content, media, and other digital resources is the cornerstone of any API integration.
Webhooks enable API platforms to push data, and notify any other URL of a change or event that has occurred via the platform. Webhooks are how API platforms become a two way street, allowing API consumers to make APIs work for them, and reduce the overhead of application usage when it comes to polling API resources. Webhooks are an API integrators best friend, and always look for them on platforms before considering which resource is best for your application or use case.
Terms of Service
Everything on the Internet today is guided buy the terms of service of web and mobile applications, and their underlying API platforms. TOS dictate how developers can use APIs, and the end-users can take advantage of services on the platform. Nobody reads TOS before they sign up for online services, but if you are looking to build a business on top of any API, you should read the TOS to see if it is something that will support what you are looking to do.
In Perfect World Everyone Provides and Consumes API
There are over thousands of public APIs available on the open Internet, and if you are building applications, you are most likely consuming APIs, as well as designing, deploying, and managing your own APIs. The best API providers, consume their own APIs, as well as the APIs of other providers. To truly understand what makes a good API, you should be consuming, as well as providing APIs.
In 2014 we are moving well beyond the old days of API mashups, or even applications using just a handful of APis. Applications are depending on entire stack of APIs, employing 10s or 100s of API resources to deliver applications across multiple web and mobile channels. Consuming APIs aren't just for developers, and about building applications, APIs are fueling many new trends that allow even non-developers to consume APIs and put them to use in documents, spreadsheets, and other common tools we depend on everyday for our personal and professional lives.