APIs (Application Program Interfaces) were a hot topic in 2014, and that seems set to continue in 2015. Rapid growth in parallel areas, such as the Internet of Things, are likely to keep the momentum behind APIs for the foreeable future.
Some companies now have an API as their primary product. Stripe, an online payment provider, and Twillo, a communications provider, are two high profile examples. Even more companies are increasing the visibility of APIs with their more “traditional” offerings. Amazon’s class-leading cloud service, Amazon Web Services, has provided an API since its launch. The API is fundamental to the service.
The standard approach to API development is to build an application, include the user interface, back-end, etc. and then expose some, or all, of the functionality of the application through an API that draws on the existing code base. The design of the API is generally driven by the design of the application’s user interface. This approach may be called “consumer-first” development.
There are benefits to “consumer-first” development. For example, the needs of the end-user act as a specification. You can be sure that the scope of the API is sufficient to support business needs as the pre-existing application already supports those business needs.
However, there is no guarantee that an existing application provides all the functionality that might be required in an API. A successful API needs to support many applications, so does it make sense to base it on one? What usually happens is that the API is built by reference to one application and is then extended piecemeal as new applications uncover omissions in the original design. While this might be considered agile, it does mean that the APIs can start to lose coherence. Refactoring can help with this, but refactoring an API is an expensive business, as it has a downstream impact on everything that uses it.
API-First development, by contrast, starts with the API. It often takes into account wider concerns, such as company strategy, in determining what features should be provided. As the API is considered in this wider context, it is more likely to be consistent. Consistency is important in an API as it’s designed for use by developers, and consistency is one way of helping to manage complexity.
APIs designed using the API-First approach are more likely to be comprehensive. As they are developed in a context much wider than that of a single application, they are less likely to exclude areas of emerging importance—and hence are more likely to be future proof. Of course, the lack of a reference application may mean that they exclude important details, but it tends to be much easier to add detail than to add entire new functional areas.
While the API-First approach does not mandate specific technologies, there are some common standards emerging:
The future of API-First development is the future of APIs—and it looks rosy. Microservice architectures allow us to build applications that are ecosystems of APIs implemented as web services. This helps enforce good development practices, such as separation of concerns.
Even governments are seeing the value of APIs. The US government’s General Services Administration (GSA) hosts a technology team called 18F that was built on the lean startup model. They are “very API-focused” and have published a set of API standards.
If you are interested in learning more about some of the issues discussed in this article, Learning Tree provides a number of relevant courses, including: