Supporting The OpenAPI Specification (fka. Swagger Specification) format when creating Web API tools is a must-have. Not for the sake of the format itself but rather because of the benefits you’ll get from it. But those benefits will come only if OpenAPI is used the right way.

OpenAPI, or the OpenAPI Specification, formerly known as the Swagger Specification, is a machine-readable and human-friendly API description format. That short description is correct but does not help to understand what it is OpenAPI: it’s the Rosetta Stone of the Web API world. Let’s see why.

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.