Member-only story
How to Create an Extension for Your Open API Specification
What do you do when you need something that OAS doesn’t handle? Create your own extension, of course!
2021 is going to be the year of the API. We’re going to focus on converging on a standard (providing public APIs) and fast-forwarding our rate of innovation.
With our focus on API design with Open API Spec (OAS), we are going to run into scenarios where some automation is needed but not currently possible. Maybe this automation is custom to you and your company or maybe it’s a service you want to provide to developers everywhere. How do we go about implementing this automation? Through the use of an extension.
An extension is a simple way to add functionality to your OAS. You add some attributes to your file, implement a handler to read it and take an action, and reap the benefits of automation!
Instead of explaining what an extension is conceptually, today I am going to walk you through the creation of a brand new one. We are going to make an extension that enhances the Postman contract test generator we made a while back.
The test generator is great, but it relies on seeded data to work properly. This means that prior to execution, specific data has to be in the database so the tests can use it.
This causes a little bit of a problem because it increases the barrier to entry. It would be nice if there was a way to use the data generated from the tests in the tests themselves. Meaning when the generator does a POST to create a new entity, it can use the id of that entity in subsequent requests to GET or update with a PUT.
Let’s walk through how to solve this problem end to end by building an extension.
Identify the Business Problem
In our example, we want to be able to use values created by the generated tests in subsequent generated tests. The business problem can be stated as follows: “I want to use dynamic variables in my tests so I do not have to rely on seeded data.”
