Used through the “try it” feature of an API’s documentation or directly called by a consumer application, an API sandbox is a great way to let developers play with an API and learn how it works without giving them access to the actual production environment. But what is an “API sandbox” actually? Is it just a mock? It can be that … or far more than that. Let’s see what could be the features of an API sandbox.

“That’s neat! The developer portal/api documentation solution we chose comes with a try it feature. Everything is out of the box, we’ll have absolutely nothing to do to allow people test our APIs.” … If only that was true. Unfortunately, there are a few concerns to be aware of to actually propose a try it feature.

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.