Blueprints

A framework to define the API lifecycle in a modular and flexible way so that anyone can define their own version of the API lifecycle using a common set of elements, questions, answers, actions, and roles being applied across standard definition of API operations.

Base

These are the base blueprints we use to define the API lifecycle, laying a base that anyone can use to define their own.

The Base of the API Lifecycle

This blueprint illustrates what we consider to be the base of the API lifecycle, providing a starting point for additional lifecycle variations elsewhere on this site. Depending on your priorities and your entry point, you may need to expand or remove from this base lifecycle to match your desired situation.


New APIs

When creating a new API there are multiple opportunities for taking a design-first approach to beginning the lifecycle.

New API Using the OpenAPI Specification

This provides a blueprint for beginning the API lifecycle by designing a new API using an OpenAPI, showing one possible lifecycle from end to end. Approaching the API lifecycle in a design-first way, while ensuring all the other essential areas of the API lifecycle are present.

New API Using the AsyncAPI Specification

This is a blueprint to try and define a new event-driven API using AsyncAPI, pushing the boundaries of this API lifecycle blueprint to include multiple protocols, patterns, and ensure that there can be a well defined API lifecycle across a diverse set of approaches to delivering APIs.

Prototype a New API Using a Postman Collection

Bringing a new API to life in a design-first way using a Postman collection to prototype the API, then an OpenAPI contract to help guide the API throughout the rest of it's lifecycle--establishing a working design of an API before you define the contract for how it will work.

Creating a New GraphQL API

This is a blueprint for pushing this API lifecycle blueprint to also work for new GraphQL APIs, identifying the steps needed to define and stand up a new GraphQL API, but then apply a consistent well defined lifecycle to how the API is moved forward and supported in production.


Existing APIs

If you are working with an existing API, these are the blueprints we recommend as your entrance to the API lifecycle.

Manually Define Collection for Existing API

This is a blueprint for how to manually create a collection for an existing API, transferring details of each request from documentation to a collection, applying authentication, then continuing to explore and troubleshoot until you have a complete and documented collection for an API.

Generate OpenAPI Using Code Annotations

This is a blueprint for entering the API lifecycle by generating an OpenAPI using code annotations, taking a code-first approach to bringing each API to life, while still ensuring that there is a contract to help guide the API across a more standardized API lifecycle.

Import WSDL for an Existing SOAP Web Service

This is a blueprint for entering a standardized API lifecycle using a WSDL for an existing web service, acknowledging that SOAP still has it's place in many enterprise environments, but a common API lifecycle including documentation, testing, and other elements is still needed.


Reverse Engineer

Often times we need to reverse engineer the APIs that already exist behind the applications we already depend upon.

Generate Collection From Web Application API

This blueprint introduces how APIs behind web applications can be reverse engineered and defined as a collection so that documentation, testing, and other common areas of the API lifecycle can be applied to help stabilize the APIs we depend on behind our applications.

Generate Collection From Mobile Application API

This blueprint introduces how APIs behind mobile applications can be reverse engineered and defined as a collection so that documentation, testing, and other common areas of the API lifecycle can be applied to help stabilize the APIs we depend on behind our applications.


Automation

These are a handful of blueprints that help automate what is happening across our API operations and teams.

Build a Business Workflow

This API lifecycle blueprint focuses on defining common business workflows, then automating around these well defined scenarios. Defining collections across multiple APIs, including authentication, scripting, data, environments, then automate using monitors and pipelines.

Test Automation

Test automation is essential for delivering reliable and consistent APIs at scale across the enterprise. This is a blueprint for walking through the base of how test automation can work as part of a well defined API lifecycle, helping teams standardize how they approach testing APIs.


Governance

These are two blueprints for helping jump start the API governance conversation as part of a well defined API lifecycle.

Design Review

A design review establishes a period in which an API designer or developer can submit an API for review by a formal design reviewer, as well as architects from a centralized API governance group, evaluating the API for compliance against an organizations governance design guidelines.

High Level API Governance

A blueprint for approach the governance of APIs from the top down, establishing a higher level strategy for defining what governance is, and then helping spread guidance across teams that helps enable them to deliver more consistent APIs across a more consistent API lifecycle no matter what type of API they are delivering.

Low Level API Governance

A blueprint for approach the governance of APIs beginning with each individual API by individual developers, setting API governance into motion at the lowest level by a single or group of developers, acknowledging that governance will only get you so far at this level, but in many organizations it might sense to start at this level.


Work in Progress

These are blueprints that are currently being defined and assembled for different areas.

About this API Lifecycle Project

This project runs on Github, and the lifecycle blueprints, elements, and actions are defined as YAML, with the website is powered using Jekyll, allowing everything to be updated in a collaborative way using it's Github repository, issues, discussions, and actions.