Evolving API Deployment to Be More Defined and Observable Using APIs

I love it when someone realizes that APIs have APIs during one of my talks or reading of of my stories. I find that people are so heads down in their daily jobs they don’t have much time to sit back and contemplate the bigger picture, which is something that might lead them to see APIs behind their API infrastructure, but also consider how it fits into the overall API lifecycle. Since 2014 I have been on a journey to produce a machine readable artifact from every stop along the API lifecycle, and the “API deployment” is one of the stops I’ve been very keen to lock down with a set of API-driven deployment blueprints that would help define, standardize, automate, and allow us to measure the deployment of our APIs. I am looking to turn APIs.json / APIs.yaml into a machine readable blueprint for API operations, and to be able to do that I need the API deployment process to be more defined and observable—something I am going to do with APIs.

API deployment is one of the toughest stops along the lifecycle to nail down because there are so many different ways in which an API an be deployed. Pick your programming language, framework, platform, gateway, service, or open source tooling, and get the job done. It is something that doesn’t always lend itself to defining and standardizing because the landscape is so define by vendor pressure and developer dogma, but I am determined to bring some order to how I define and deploy APIs using a variety of common approaches. The first API deployment blueprint I’d like to share is my collection for deploying a simple API to AWS API Gateway backed by DynamoDB—-here is a walkthrough of how the API deployment blueprint collection works.

This is a very simple approach to API deployment. The blueprint won’t handle very complex schema, and there is no layer for business logic. But for a simple one dimensional schema, it provides a pretty quick and dirty way to deploy an API in 10 steps. The blueprint can use more work making it a little more robust on search, filtering, performance, and other areas, but he gives me a series of known API requests for turning an OpenAPI specification into a real world read and write API that requires an API key to access. My simple API deployment process is defined by a 10 step collection that is documented and can be run manually, scheduled via a monitor, or as part of a pipeline using Newman. Providing a set of known inputs and outputs for the API deployment stop along a known API lifecycle.

Every time I run this collection it stores the state of the API deployment in a Postman environment>a. This concept pushes the boundaries of what you use Postman environments for, but it works well for providing me a machine readable snapshot of the deployment stop along the API lifecycle. Providing me with timestamps for deployment, evidence of a plan for API management, and how an API is being secured using keys, further making things observable using API management and logging provided by AWS API Gateway. Now I can share this blueprint with other developers, allowing them to fork the collection and make it work for deploying simple APIs defined using OpenAPI, and submit pull requests for any enhancements to the API deployment blueprint. Next I will share the serverless version of my API deployment blueprint, using RDS instead of DynamoDB as the database, and adding a layer of logic using AWS Lambda. Pushing forward the blueprint for how I not just deploy my APIs, but how I define and observe the API deployment process as part of a wider API governance strategy, all demonstrated via a Postman public workspace.