API-Centric Architecture: All Development is API Development
Developers and architects often think of APIs as a continuation of the integration-based architectures that have long been in use within enterprise IT. But this is a narrow view.
This post is the first in a series that will examine the broader reality, where APIs have become a foundational technology for the development of robust and scalable enterprise applications. We will examine some of the important implications of the movement to the API-centric architecture that is underway within enterprise application development.
All development is API development
Today’s software is built as services. Rather than using web frameworks that invoke services and produce web pages, today's applications are built by consuming and producing APIs. Applications have embraced APIs on the front end for connecting to rich clients; on the backend for integrating with internal systems; on the sides for enabling other applications to access their internal data and processes; and within, as applications are composed of a set of component services, linked together with APIs.
The majority of enterprise software development efforts are focused on building web applications using web frameworks. Java Enterprise Edition, Microsoft .NET, Ruby-on-Rails, PHP, and a variety of other technologies are used to implement web applications using model-view-controller (MVC) design patterns and page template technologies. For a decade, starting in the late 1990s, an entire generation of developers has spent the majority of its time building applications in this model.
APIs move to the front end
Web application developers found it necessary to create APIs to allow communication between the browser and the server.
Mobile forces the issue
The mobile app represents a return to the more strongly delineated client-server model of development, where all interactions happen client-side and a constant networked communications mechanism between client and server must be maintained.
The client/server communications mechanism in the age of mobile is APIs. In some cases, the same developer is charged with building the server-side and client-side interactions, but in other cases, it became necessary to have specialists building each client implementation. Further, these specialists are often external contractors, digital agencies, or system integrators.
This means that the application development effort needs to have an API project at the heart of it. Application developers not only need to know how to consume an API, but have to understand how to produce one as well, with all the attendant issues such as API design, API security, and API scalability.
APIs open enterprise applications
Integration architectures assume that applications are developed without considering whether to enable other applications to access their internal data and processes. Before the conventions of APIs were widely adopted, this was a prudent strategy. Trying to support application-to-application integration was an undue burden for the developer and was usually left as a project for another team.
The result: when the time comes for application-to-application integration, the need for separate integration middleware is obviated.
Next time, we’ll discuss how SOA is giving way to micro services architecture as applications themselves are built from interconnected micro services wired together via APIs.