This is the first of two articles on the growing trend of API-first design. In this article Patricio Robles takes a look at some real-world examples to illustrate why API-first design is an emerging trend. Robles’ article will be followed by an interview with Uri Sarid, CTO of MuleSoft (parent to ProgramamableWeb), who spoke with ProgrammableWeb about the advantages and approaches to API-first design.
How an API was designed and implemented is usually of little interest to consumers of the thousands of APIs available today. What matters most is that an API works, is easy to integrate and solves a real problem. But for the growing number of companies looking to take advantage of the booming API economy and considering developing APIs, design is an important subject.
Historically, API design has been a consumer-first exercise: a company develops a data-rich application and at some point, decides to build an API through which that data can be accessed. In recent years, however, more and more companies have opted for an API-first approach under which APIs are designed, implemented and documented before the application that will consume them even exists.
The API-first approach has gained momentum for a couple of reasons.
First, we now live in a multi-screen world where few businesses have the option of building a single application for a single device. Many companies have found that building an API layer that can serve all of their applications is the most sensible strategy for efficiently developing and maintaining desktop, tablet and mobile apps, whether web-based or native.
Second, it is now possible to build a successful business with nothing more than an API. Just a few short years ago, the notion that companies could survive with an API as their sole product offering would have seemed questionable to many. Today, a growing number of companies, from payments provider Stripe to telephony provider Twilio, are proving that it is entirely possible.
Despite the growing popularity of the API-first approach, the consumer-first strategy retains some attractive features. For instance, a working application that consumes an API can reduce the number of assumptions that are made around API endpoints and parameters. In other words, an existing application can be a valuable reference for API design.
But having a good understanding of what your API must support doesn’t necessarily mean that implementation is painless. A reference application won’t necessarily encompass all the use cases that an API may be asked to support, so a consumer-first process can never guarantee a good API design. And for some companies, particularly those with large, complex applications, implementation can be difficult. This is especially true when dealing with legacy systems.
Case in point: EDGAR Online, a prominent provider of financial data, which is in the process of modernizing how it provides its data through APIs. As EDGAR Online President Dave Frankel detailed in a recent ProgrammableWeb interview, because of “antiquated systems,” developing the kind of API access that customers increasingly want has been a significant undertaking for his company—even though it already had a foundation to build on. “Our old environment is not able to provide [what is needed],” Frankel explained.
That highlights one of the strongest arguments in favor of an API-first approach: It affords companies the opportunity to avoid the technical debt that often builds up around legacy applications. From day one, it is possible to focus on developing the API, without the technical issues that can distract from the process.
Starting with a blank slate has obvious appeal, but companies adopting the API-first approach also face a number of challenges that must be addressed. Absent real-world context, for instance, an API-first process can produce an API that doesn’t actually provide the functionality developers need to solve their problems.
To address this, Leore Avidar, the co-founder of Lob, a startup that offers an API for printing and mailing, believes that companies should work closely with their first users. “Don’t be afraid to break the structure of your API” in the early days, he suggests. “Find a few key customers that are willing to work with you and keep in constant communication with them. This will allow you to change the API given their comments.”
Avidar also recommends that companies become consumers of their APIs, even if they’re not focused on building customer-facing applications. “Whether you are building your website using your API or building sample applications it will help you anticipate how your clients will use it as well as find all the early bugs and problems,” he says. Some level of domain expertise is also important. Prior to co-founding Lob, Avidar worked for Amazon Web Services and says his experience there gave him knowledge of API design best practices and prepared him for the challenges associated with building an API.
The good news for companies considering an API-first approach is that best practices have emerged which didn’t exist a few years ago. The word “API” is going mainstream, making it easier to find and communicate with potential users. And with thousands of APIs of all shapes and sizes available, companies have a significant number of working examples and sources of inspiration.
None of this means the consumer-first approach isn’t viable, or more desirable in some cases. But as the API becomes a first-class citizen as far as interfaces go, expect to see more companies adopt the API-first approach—and, most importantly, get it right.