What would you do if you had to demo API to non-developers in a highly-constrained context? How would you do without curl, Postman or any other API tool usually used? How would you do without your usual fun API examples? I had to do that a few weeks ago and was quite happy by the questions that arose and the solutions found. The whole story definitely deserves a post in order to share what I’ve learned!

Explore subterranean needs! Plunder hoards of inconsistency! Battle legendary design flaws! The API Design Reviewer’s Starter Set is your gateway to exhaustive and constructive API design reviews. It contains the essential rules of design reviews plus a few tips and trick that will be of great help on your perilous adventures in the API world.

There are quite many APIs out there taking advantage of all standard HTTP methods (GET, POST, PATCH, PUT and DELETE). Unfortunately, there are still some cases where consumers can’t use them all. As far as I know, GET and POST do not cause any problem at all. But as an API provider, do not take for granted that DELETE, PUT and the more dreaded PATCH HTTP methods can always be used by your consumers. I encountered this problem several times throughout the years and no later than a few weeks ago. Let’s see why and how to solve this problem.

At last, my book The Design of Web APIs is finished and printed! I gradually got back to a “normal” life since the end of summer as the book entered in its production phase, but it was only when I received the printed copies two weeks ago that I had the feeling that this adventure was really over. And then holding the book in my hands, I wondered if it was worth having spent two years of my life on it, what did I learn spending almost all my free time working on this book? That sounded like a good topic to revive the API Handyman blog.

Well-designed APIs are a joy to use; poorly-designed APIs are cumbersome, confusing and frustrating, just like everyday things. During this session, I make a parallel between everyday things design and API design to expose simple but fundamentals design principles.

So you want to explore in depth the OpenAPI Specification version 3.0? You should take the OpenAPI Map with you!

While answering some question on my Design of Web APIs book’s forum, I wrote:

Now that I have seen brilliant Web APIs that can be used so easily because of their design but also the overall experience some can provide (the famous “DX”) I have become far more demanding and challenging with software in general

Yes. Public web APIs definitely raise software bar. The whole software industry should take example on them …

I’m thrilled to announce that I’m writing a book about API design: The Design of Everyday APIs (edit: the book has been renamed The Design of Web APIs since this post has been written). This book is published by Manning Publications and the first two chapters are now available on the Manning Early Access Program or MEAP (affiliate link, use fcclauret discount code to get 37% off). This book is for everyone who wants to learn API design. But, what’s the story behind this book about API design? To answer this question, let’s talk about my other passion: guitar.

Join Frodo, Gollum and Gandalf on an epic API design adventure. In this session, based on my own experience defining and sharing API design common practices in my company and based on the API styles guides that I have collected on apistylebook.com, we will discover why we desperately need API style guides and how they can or cannot help us create a smooth API surface for a company.

I’ve added the Deliveroo API Design Guidelines to the API Stylebook.

These guidelines are definitely a MUST read for any API designer.

To discover this API design guide and a short review, let’s go to the API Stylebook blog.