In the collective unconscious, API governance often rhymes with API police. Reducing API governance to the need for order caused by the chaos of an organization’s myriad APIs is too reductive, and it risks not looking at the problem at hand from the right angle. Why not define API governance relatively to IT governance, corporate governance, and governance to better understand what it is?

The info property of an OpenAPI document contains metadata that provides an overview of an API, but what does it represent exactly? How did it evolve across the OpenAPI Specification versions? And how to can it be used and misused? This is the second post in the OpenAPI Specification Reference series.

L’idée folle de l’équipe Microsoft User Group France pour API Days Paris 2021: un clash REST (représenté par votre serviteur) vs GraphQL (représenté par Jonathan Jalouzot, tenancier du Meetup GraphQL Paris) arbitré par Nicolas Barrasson.

Had a great time chatting with Erik Wilde about the motivation for writing The Design of Web APIs book, and why it specifically focuses on the design aspect of the API lifecycle (and also why it is not titled The Implementation of Web APIs).

I started this project with a simple API Design Guidelines list in mind and ended with a fully analyzed collection of API design guidelines. I created it for others but I use it myself too. When I wonder how to handle some API design matters, I select the related topic and read how others handle it. To be honest, it needs some refresh, it is a real pain to update and maintain and could be more user friendly; that’s on my todo list.

I built the OpenAPI map because I was constantly searching for “how do this with the OpenAPI spec” and also “but where is that thing” in the specification. Having the OpenAPI specification represented as a tree given essential information and quick access to source documentation of each element saved me countless time.