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!

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.

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. 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.

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.

Getting, creating, updating or deleting multiple resources in a single API call is a common need in REST APIs. But how to achieve that in a consistent way accomodating how we work with a single resource and REST principles? This is what we’ll see in this post.

The OpenAPI Visual Documentation has been updated. The new version 3.0.0-rc0 of the OpenAPI specification has been added. The addition brings a fully detailed change log of what has change from version 2.

I’ve just added the Google API Design Guide to the API Stylebook. This guide is slightly different from the other ones because it deals with REST and RPC API design focusing on gRPC APIs using Protocol Buffers v3. To discover this API design guide and a short review, let’s go to the API Stylebook blog.