If you believe the tech press, you should have an API because.. well.. everyone should have an API. While this is great for API management companies, it doesn’t really apply to everyone. If an API doesn’t provide tangible value to at least one major constituency within your organization, it is doomed to failure.
Here are seven primary reasons why an organization might need a REST API with focusing on security-first design.
1. Mobile Strategy
The first business reason for an API is a mobile or mobile-first strategy. In most organizations, there are neither the time nor the resources to build tools for every single device.
An API can ensure that additional - either less important or even unexpected - devices are addressed. In addition, it may parallelize the effort to create a presence much faster or differently than originally planned.
A real-world example is Netflix. When Netflix originally started mailing DVDs in
1997, its competition was Blockbuster and the cable providers. Over the next few years, Netflix quietly consumed the DVD rental market while they prepared to launch their streaming service in February 2007. Seventeen months later in October 2008, they launched the official Netflix API with a simple goal and a strategy to get there by partnering with developers:
Millions of people love movies via Netflix, making this API an opportunity for all kinds of developers to add well-known value to any other application.
The company says the API will allow access to data for 100,000 movies and TV episode
titles on DVD as well as Netflix account access on a user’s behalf.
As a result, there were Netflix applications for most common devices within weeks or months.
These initial applications provided customers with the ability to view and manipulate their queue whether they were online or offline. More importantly, it began to make Netflix a tiny - yet constant - part of everyday entertainment consumption.
By the time Blockbuster entered the streaming market and later when they launched an API, Netflix was already the defacto standard. At that point, if a device had a full-color screen, no matter its manufacturer, size, or profile, there was a Netflix application available that could enable watching a movie in just minutes.
2. Drive Usage
The next reason for an API is to drive usage of a platform. Notice that this isn’t necessarily paid usage but usage in general.
Why is this scenario useful?
By focusing on fast and simple usage of a platform, you can drive engagement and grow the user base even more. Twitter is a prime example. Their API
was probably one of the most commonly cited for simplicity and ease of use. It was so easy that many coding frameworks changed their sample “getting started” project from “hello world” to “hello twitter.” In a matter of months, there were literally hundreds of Twitter apps available on every device, ranging from desktops to browsers to more unique devices.
Twitter was not the first instant messaging or chat app and it has had to deal with competitors since its launch. But by being ubiquitous on every device, allowed people to step away from their computers and engage with the platform how and when they wanted. As a result, people used the platform more often than the alternatives. As people used the platform more, more people had to stay connected to it more often, further driving both passive (viewer) and active (tweeter) usage. This became evident at South By Southwest 2007 when a mobile-centric, desktop-disconnected audience found it as the primary means to trade information, keep in touch, and find out what others were doing.
Ubiquity may not have been their original goal for the API, but it created a virtuous cycle of usage driving viewing and viewing driving usage.
3. Defensive
The third reason for an API is purely defensive.
This is somewhat parsing words from the previous two scenarios but is distinct in a number of ways: when you’re an established player in the market and competition disrupts your business, it can be a challenge to use your positioning, information, and infrastructure to make your existing business lines more stable. An API strategy
may be able to launch you into new business lines and growth that was previously unrecognized.
The big-box retailers have suffered the brunt of this sort of disruption. They have massive stores with massive inventories where they suffer from the “showrooming” problem. Potential customers come in, browse the merchandise, and once they find the item, they use a site like Amazon to find a better price and place the order. The customer walks out without the product but saved money and the retailer missed a potential sale.
Best Buy is working to turn that tide. By opening their API and making massive amounts of data open to third parties, they have been able to build a community that is willing and even excited, to explore the data and ways that it can be used. Some of the apps range from simple inventory explorers, but others include republishing the deals and discounts they are offering in-store. Yes, people are sharing ads on purpose. To date, it has had a significant impact on their bottom line with a 15% increase in online sales in Q3 2013.
4. Partner Connectivity
The fourth reason is to improve connectivity with partners and suppliers. In the past, many organizations exchanged spreadsheets via email to update systems such as inventory management. If they were more advanced, the spreadsheets were uploaded via FTP and parsed automatically.
Either way, these methods were error-prone and often fragile when changes would occur within either system. When importing a spreadsheet, a missing or new field, or even a misplaced comma, could cost hours of effort and delay expensive processes. Fundamentally, it was broken.
Alternatively, using APIs can provide a repeatable and consistent way to exchange
information. The FedEx API demonstrates this from two different angles. First, by providing tight integration, an organization can simplify its own logistics by building on those within FedEx. On the other side, the organization’s customers gain a great deal of insight into shipping, which was an opaque process just a few years ago.
5. Abstraction of Complexity
Powerful and important systems are almost always complex to use and integrate, often out of necessity. In the earliest days of the web, it took knowledge of the C programming language and a detailed understanding of SMTP in order to send an email. As these systems have become more important and widespread, they have become easier and less complex to use and integrate into our systems. This ease and simplicity come from APIs.
SendGrid simplifies sending & tracking email At this stage, the code required to send an email is quite simple. Unfortunately, this simplicity doesn’t include clickthrough tracking necessary for many emails. It also doesn’t include configuring email servers that are resistant to both sending and receiving spam, delivery reports, open reports, and a variety of other aspects that are useful to you and your organization.
Every single one of those features is additional code to write and maintain
in the future. On the other hand, SendGrid has a simple API for sending emails. It only takes minutes to integrate into a system. The fundamental difference is that it does all of the above features - clickthrough tracking, spam resistance, delivery & open reports, etc - automatically. You don’t have to do anything extra, just use the API.
The API takes what is otherwise a complex system and allows you to make use of massive functionality in mere minutes with just a few lines of code.
6. Simplifying Interfaces
Despite numerous technical standards and long-established players, some systems are still terribly complex to interact with and use in general. One of the prime examples is your email inbox. Despite only two standards - POP3 and IMAP - there are so many implementations and variations of those implementations that what should be a handful of lines of simple code ends up being a deceptively complex implementation handling dozens of edge cases and unique scenarios. Building yet another email interface is a practice in futility likely to cause unforeseen schedule delays and unnecessary complexity. It’s simply not worth the time or energy.
Context.io gives you an API for your inbox. In this scenario, an API can wrap all
these variations and oddball cases and instead present a single unified interface for developers to use. The Context.io API does exactly this. To interact with an inbox - whether Microsoft Exchange, Gmail, or something else entirely - you initialize the inbox with your email credentials and then it transparently handles all the detail, complexity, odd scenarios, and other situations that occur. What could easily take days of effort is simplified to minutes. More importantly, it doesn’t matter if the inbox is hosted in Microsoft Exchange, Gmail, or anything else, all are used exactly the same way with the exact same commands.
The most powerful aspect is that the developer doesn’t even have to know which email provider is being used. It’s completely transparent.
7. Metered Usage
Many services lend themselves to simple monthly or flat rate pricing. For example, sending an email has a marginal cost that is effectively zero so sending the hundred and the first email costs nothing more than the hundredth. Alternatively, if we consider a resource such as CPU or processing time, the costs of running a server for two hours are effectively double the costs for one hour. In this case, a consumption-based or metered pricing model makes more sense. This is also known as “utility
pricing” to represent that you are only billed for the portion of a resource used.
This is key for scenarios where massive amounts of processing time or power are required for short periods.
A few years ago, the New York Times had just this situation where they had 130 years of articles, approximately 11 million in total, which needed conversion into PDF documents. To solve the problem, they turned to Amazon EC2 to increase their processing power. As a result, the Times was able to temporarily utilize 100 servers to generate all of the required PDFs in under 24 hours. At the end of the project, the Times released those servers and was not charged any further.
Final words
Of course, none of these scenarios are mutually exclusive. An API can be used to simplify interfaces, hide complexity, and still create a system for metered usage.
While reasons 1-4 are more business-oriented for having a REST API and can be hard to quantify and therefore even harder to measure, reasons 5-7 are more technical and are relatively simple and straightforward. Some companies already opened new vacancies for special API developer jobs in order to speed up the API building process.
Most developers understand
building systems to make use of complex systems is a painful experience that they’d rather avoid.
More importantly, they understand that replicating these systems in-house often requires a huge amount of time and effort and is error-prone. At the end of the day, building and using these APIs can save time, money, effort, and untold amounts of stress for all involved.