Become a Pro at API Management: A declarative approach

Presented at API World 2019 and API Specs Conference 2019.
OpenAPI has become the standard way to describe APIs and Services but when it comes to runtime configuration, it’s a Tower of Babel: each vendor takes a different approach, or worse, DevOps are forced back into a UI, with no good way to script and automate deployments. We’ll examine the current state of declaring configuration in API Definitions and examine proposals to improve infrastructure as code via OpenAPI.

Transcript

1. Become a Pro at API Management: A declarative approach Emmanuel Paraskakis |@manp VP Product, SmartBear
2. Proprietary & Confidential 2 Configuring API Management today – UI or CLI/API
3. Proprietary & Confidential 3 UI - Great for getting started, but… • No repeatability – maybe dump/restore a config file? • Can’t easily see differences between configs • Not easy to version • Not easy to share/collaborate on • Start from scratch every time • No templating/reuse/examples • Configuration proliferation and drift
4. Proprietary & Confidential 4 Better: Declarative Config • Like code… so you can diff it, check it in • Can view/share entire config in a doc but… | Usually proprietary format | duplication of API Description… | what if I already have an OpenAPI doc?
5. Proprietary & Confidential 5 Best: Reuse API Description • Add “vendor extensions” to your OpenAPI doc (inline) • Reuse of paths, methods and other elements • Use a single document as Source of Truth • Minimize inconsistencies but… | Vendor extensions are not part of the standard | They are different for each vendor, not only in syntax, but in scope/purpose
6. Proprietary & Confidential 6 Can we do better? • What if runtime configuration were part of OpenAPI? And vendor extensions were unified and part of the standard? What we have already: | Use “servers” for environment configuration | Use “security” “securitySchemes” for authN What we’re missing: | A “backends” object | Request and Response Policy spec | Analytics config/aggregation Servers Backends Security Request Policies Response Policies
7. Proprietary & Confidential 7 Servers Servers Backends Security Request Policies Response Policies
8. Proprietary & Confidential 8 Security Servers Backends Security Request Policies Response Policies
9. Proprietary & Confidential 9 Request Policies Servers Backends Security Request Policies Response Policies
10. Proprietary & Confidential 10 Backends Servers Backends Security Request Policies Response Policies
11. Proprietary & Confidential 11 Response Policies Servers Backends Security Request Policies Response Policies
12. Proprietary & Confidential 12 What’s next? • OpenAPI Proposal to support Runtime Configuration: • Request/Response Policies • Backends • Analytics Aggregation • OpenAPI Proposal for Overlays #1843 • OpenAPI Proposal to extend support for Substitution Variables Credits for Inspiration: Mark Foster Vincenzo Chianese