The adoption of machine-readable contracts by gateways is one thing, but the scope of that adoption is really where the rubber meets the road. Meaning is this machine-readable contract used as an input and an output, but also the most telling characteristic of an API gateway is whether or not a contract exists for the API behind a gateway, and whether or not you can use an API to declaratively configure each API within the gateway using the API — meta-level stuff.
These are the elements.
- Import - You can import an API contract to override the definition of an API at any stage.
- CI/CD - You can configure a gateway using the Open via existing CI/CD workflows.
- Publish - The API contract can be published or discoverable as part of the gateway operation.
- Export - You can export an API contract from a gateway that represents the current truth.
- API - You can programmatically manipulate the API contract for any API in a gateway via the API. Those were the elements. This area is really the most defining characteristic of what I’d consider a next-generation API gateway. This is where I will be putting most of my chips when betting on what API gateways are going to survive the next round of competition. Your support of API contracts at this level within your gateways shows your understanding or lack of understanding of how APIs are wielded upstream and downstream.