11436 SSO

API-Centric Architecture: All Development is API Development

Ed Anuff
May 08, 2014

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

The advent of Web 2.0 brought a renaissance to rich client development. The incompatibilities and inconsistent implementations of JavaScript began to ease as users updated to the latest browsers. At the same time, renewed competition in the browser market drove more innovation and acceleration of the implementation of web standards.

  • HTML5 and JavaScript made it possible for much of the interaction to run in the browser rather than to be orchestrated via page-based flows.

  • Web application developers found it necessary to create APIs to allow communication between the browser and the server.

Over time, these techniques accumulated, with more and more functionality that had previously been implemented in page templates becoming replaced with API calls. The end-result is what's now called the “single page app,” or SPA. At this point, no user interactions are serviced via page templates. A single web page is served and all interactions are handled via JavaScript, which generates a user interface via HTML5 techniques and libraries such as jQuery. Nearly every user interaction generates API calls to support these interactions.

As this model of web development became common, traditional page-based web analytics was hampered, but developers soon found that moving to API-based interaction analytics gives them greater abilities to capture and analyze web usage. JavaScript enables detailed observation of where app users spend time and what they are doing within the applications. These analytics can be transmitted to analytics APIs in a constant stream of interaction data.

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.

For mobile apps, the API-driven UX becomes non-optional. Unlike the web application developer, a mobile developer cannot choose the interactions to support via HTML and JavaScript versus those driven via traditional page templates.

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 widespread adoption of the basic conventions of API design—RESTful design, JSON-based data, simple versioning, and key-based access control—means that developers can easily build APIs into their applications and support their usage without undue distraction from their central mission of application delivery. And because application delivery already requires an API-centric architecture to enable rich HTML5/JavaScript and mobile clients, APIs will be essential elements of the project scope.

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.

API Management Decision-Making Kit

Next Steps

 
 

Resources Gallery

News