Anton Babadjanov / Matthew Farmer Program Manager / Senior Program Manager - Microsoft Manage API lifecycle sunrise to sunset with Azure API Management

The stages of your API Programme Deploy & Run Design & Develop Manage Change

Design-first Many drivers of design-first approach Quick start unburdened by prior tech debt Multi-channel development Collaboration between API and app dev Iterate & spot issues early

Design-first APIs DEMO

Many approaches to CI/CD PowerShell Azure Resource Manager Git

Managing in production DEV TEST Source control ARM Merge ARM API ARM API Build agent ARM

Deployment lifecycle with ARM DEMO

Versioning is a highly debated subject Version or not? Semantic versioning? What is a breaking change? Where to place version information? Path? Query? Header? Media type? How to identify version? Number? Date? Name? Versioning debates haven’t been definitively settled. Some advocate immutability. Others, different kinds of versioning approaches, e.g. semantic versioning. Even a seemingly simple question of what constitutes a breaking change is a subject of many arguments. Each way of conveying version information has its pros and cons.

Our approach to versioning Natively understand versions at the system level Versioning is an opt-in Offer versioning scheme options Inform developers about the changes Control when the changes get adopted Versions Revisions In light of that, we decided to provide a mechanism and leave the job of setting a “policy” to customers. First off, we don’t force anyone into versioning. We offer a selection of popular versioning schemes. We classify changes into two categories and treat each as a first-class concept in the system. Revisions allow API publishers to make, validate and apply, usually non-breaking, changes to an API without fear of breaking its consumers. Versions enable API publishers to evolve the API in more significant ways and allow app developers to opt-in into those changes whenever they are ready. Consumers choose when to adopt Providers choose when to deploy

Versions and revisions in API Management Service Instance API Version Operation Revision /v1 ;rev=1 ;rev=2 ;rev=3 /speakers /sessions /days ;rev=4 https://example.org/ foo [ANIMATED SLIDE] Here is the pre-version API model. Everyone is leaving in it now and can continue to do so. But there is a richer model if you decider to take advantage of versions and revisions. As you can see, each API can have multiple versions. And each version, multiple revisions. At any given time only a single revision is active - marked in red. Revisions can be “online” for testing (solid green) or “offline” (light green). /v2 ;rev=1 ;rev=2

Versions & Revisions DEMO

The stages of your API Programme Environments, API, PowerShell, Git, ARM Design 1st, Mocking, SOAP to REST Versions & Revisions