After my first recorded live demo session, here comes my first non recorded actually live session in which I show how I take advantage of the OpenAPI Specification during API design reviews. Note that I experienced some technical issues during this session, you’ll find the story in my “Barely surviving my first live (non recorded) demo session” post.

API all the things! Whatever the reason, IT optimization or digital transformation, it’s nowadays fairly common to APIfy an existing system, making it available through APIs. What is also very common is to not totally grasp the implications of doing so and especially overlooking complexity, security and capacity concerns.

I was invited by David Brown and Kevin Montalbo for Toro Cloud’s Coding Over Cocktail podcast. We discussed API consistency, how to make your APIs more discoverable, defining and setting the boundaries between an API gateway and API implementation, and choosing the right API architecture and technology for the right problem.

I was invited to Stoplight’s API Intersection podcast hosted by my two good friends Jason Harmon and Adam Duvander. As it was Stoplight’s “Style Guide September”, we discussed one of my favorite topics, covered quickly in my book The Design of Web APIs, and that I practice everyday helping people to create APIs: API design style guides.

I regularly participate to CFP (Call For Proposals) aiming to choose a software solution. My role is to analyze solutions from an API perspective. And I do that even if there’s no specific API concern regarding the context in which the CFP is made. Why doing so and what to look at? This should be of interest for people having to choose a solution but also to people proposing them. Indeed, some (corporate) software solution vendors should take this seriously … Unless they want to finish at the bottom of the list.

If you’re an API design reviewer and, like the Who, you got a feeling inside that you can’t explain during an API design review, maybe you’re falling in love with the API designer… or more probably: you’re on the verge of giving an opinion. And that is a problem. What is the role of an API design reviewer? Distort API designs to their liking or objectively analyze them based on facts?

Fifth and last post about my first ever (recorded) live coding session given at the Manning API Conference. Thanks to all the work done, I had a good setup, great visual style, titles over VS Code, speaker’s notes and was able to code at light speed. But I was hesitant and not fast enough when presenting, I needed to train myself and fine tune, optimize or remove content to make things smooth and keep in given time frame. And once again VS Code went to the rescue.

This is the fourth post about my first ever (recorded) live coding session given at the Manning API conference. In this series second post, I listed some problems I encountered and started to solve them in previous post. But there are other problems to solve, one of them was that I was not coding and using VS Code fast enough. In this post, I’ll show you how I solved that using a few VS Code tricks, the most important one being: the absolutely rad custom code snippet feature.

C’est avec un grand plaisir que j’ai répondu à l’invitation de Stéphane Beuret pour parler d’API (en français pour une fois) dans son podcast Electro Monkeys. On y parle de lavabo, de mon livre (The Design of Web APIs, en anglais lui) mais aussi et surtout de design d’API, de sécurité, cycle de vie et gestion des erreurs. Toutes ces choses auxquelles il faut penser pour faire de bonnes API Web.

Third post about my first ever (recorded) live coding session given at the Manning API conference. In previous post, I encountered various problems. Two of them were related to not delivering the session like one of my regular slide deck presentation. I wanted to add titles and have speaker’s notes. In this post, I’ll show you how I solved those two problems with OBS, VS Code and a little bit of magic.