When linting an OpenAPI document (or any other JSON or YAML document with Spectral), the hardest part is ensuring you’re not missing your target and so be sure that expected checks will be done. In this post, we’ll see how to be sure a Spectral rule will be triggered when checking the presence of an element.

As API governance often rhymes with “policy enforcement,” API contract linting can be seen as the panacea of API governance: it can be used to ensure API contracts conform to pre-defined rules. But both API linting and API governance are more than that. Let’s discover the contributions and limitations of API contract linting in API governance.

Let’s compare versions Swagger 2.0 and OpenAPI 3.0, and 3.1 to demonstrate the benefits of the new features introduced by 3.x versions to create more precise, better documented, more practical, and future-proof API contract descriptions.

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.

The OpenAPI map needs a refresh to supports OpenAPI 3.1 and I wanted to do a similar thing for AsyncAPI. I started to work on toolings that takes the OpenAPI markdown specification and turn it into data and I built a prototype to render it. Everything you want to know about each version of both specifications is there.

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.