Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Become a Pro at API Management: A declarative a...

paraskakis
October 10, 2019

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.

paraskakis

October 10, 2019
Tweet

More Decks by paraskakis

Other Decks in Programming

Transcript

  1. Become a Pro at API Management: A declarative approach Emmanuel

    Paraskakis |@manp VP Product, SmartBear
  2. 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
  3. 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?
  4. 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
  5. 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
  6. 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