I did my first ever (recorded) live coding session at the Manning API conference. During 30 minutes I talked and coded … without any slides; that was totally new to me. While it started well, preparing and recording this session turned out to be quite complicated. At some moment, I was totally desperate and I thought I wasn’t going to make it. But I did it and learned a lot of stuff that deserves to be shared. In this first post, I’ll talk about how “it started well”: setting up OBS, mic, cam and VS Code to record myself speaking and coding.

An API gateway is a proxy that sits between API providers and their consumers. Its main role is to ensure that only authorized consumers consume some APIs. But API gateways usually come also with features such as request/response transformation and some of them even allow to code complex orchestration. Such transformation features can be very useful if used wisely. But they also can give terrible ideas with terrible consequences.

How many times people realized that an API was not so secured despite being exposed on an API gateway? Too many times. While being a must have to securely expose APIs, an API gateway will not do all the security work for you. Security in general, and API security in particular, is a matter for everyone. Let’s see what is the job of an API gateway and what you still have to do to actually securely expose APIs.

When reviewing API designs, I often encounter operations such as GET /resources?queryParameter=value where the query parameter is required. Consumers won’t be able to make that request without providing this parameter and a correct value; that’s usually a problem. Indeed, at best it will ruin developer experience and at worst it is a sign of design smell. Let’s see why.

Nobody expects the API inquisition! Literally. When creating public or private APIs, an organization must work hard on creating the best possible developer experience or DX. That requires to ensure that API designers “do their job well”: creating APIs that fulfill actual needs and are easy to understand and use. This is the aim of governance which may help creating the best APIs or may slowly killing the organization, depending on the designer experience, the other DX, it provides.

What if I tell you can run Postman collection inside Github Actions and so easily automate all the things as long as they provide APIs? Sounds interesting right? So let me show you how I migrated my Jekyll blog publication workflow to Github Actions and how I used Postman collection to clear my Cloudflare cache. Bonus: You may also learn a few things about DX and API design.

More often than not when people hear “let’s do an API design review”, they hear “let’s check that an API design conforms to API design guidelines”. That’s only partially true and reducing API design reviews to that is a terrible mistake. Actually, doing API design reviews only to do that may even not make any sense at all. Let’s see 3 really good reasons to do API design reviews.

In (Ch-ch-) Changes, David Bowie sang “Every time I thought I’d got it made, it seemed the taste was not so sweet”, that’s a good metaphor for API design. An API will irremediably evolve because it will lack some features or because of mistakes, and so sooner or later, you may have to introduce a “breaking change”. That’s usually when people start to run in circle, scream and shout “Oh! Please no! Please, not a breaking ch-ch-change”. But, what is it actually? How to handle it? And should you always be afraid of it?

It is usually considered a terrible practice to name a property or a function with a meaningless name when writing code. But surprisingly, when it comes to choosing application or API name, some people tend to choose names in a more artistic way (says the “API Handyman” who can name some tool “OpenAPI Chainsaw”). So let’s see 3 reasons why choosing a not meaningful API name can be a problem.

When designing APIs, choosing HTTP status codes is not always that obvious and prone to errors, I hope this post series will help you to avoid common mistakes and choose an adapted one according to the context. This fourth post answers the following question: given that /users is a collection (a list) and no users are named Spock, what should return GET /users?name=spock? 200 OK, 204 No Content or 404 Not Found