API Reference Architecture Model

15 Feb 2018
by: Patrick Chipman

This Reference Architecture is an overview of the runtime components needed for the effective, mature delivery of APIs. In our reference architecture, legacy services and data are consumed by APIs, which either proxy calls to enterprise services or use microservice aligned data stores to provide accelerated query delivery. A CDN and caches improve the delivery of large entities and slowly changing data. Virtualized endpoints enable a “sandbox” where external developers can test their consuming applications against realistic simulations of production. IdP and IAM systems provide security, while the API portal enables the consuming developer experience. External and internal monitoring systems provide proactive notifications of problems in your APIs. In the middle of all of this, the API Gateway provides centralized management of security, transformation, and routing.

API Reference Architecture


  • Threat Exposure Management
  • Endpoint Monitoring and Alerting

Legacy Systems

  • Enterprise Service Delivery
  • Shared Data Stores
    Data Stores shared by more than one application or for the general operational storage of data.

API Systems

  • Internal User IdP
  • External User IdP/IAM
  • API Gateway
  • CDN
  • Cache
  • API Portal
  • Virtualized Endpoints
    A functioning mock of each API, creating a production sandbox to serve consuming applications’ SDLC.
  • Operational Monitoring
  • API Delivery
  • Microservices Aligned Data Stores
    Data designed and stored for the purposes of organization and agility.

However, this reference architecture only covers runtime components. A mature API program also includes lifecycle components not depicted here. These include interface editors and collaboration tools that you can use to develop API definitions and iterate on them with your consumers, as well as continuous delivery tools to deploy APIs in an agile way. Another key lifecycle component is the formal definition, made up of business use cases and test cases, which defines the behavior of the API and guides its development. These lifecycle tools are described in our series on lifecycle tooling. Beyond these, though, none of the business processes needed to support the API program, such as governance, a Center of Practice model, or cross-functional teams, are depicted here.

As you can see, a solid bedrock of tools is necessary to enable an API program, but there’s far more to API delivery than just an array of software. Vanick Digital has the experience and knowledge to help you select and implement the reference architecture, lifecycle tools, and business processes necessary to unlock the value of consumer-driven APIs.