Ever wanted to quickly find, extract or modify data coming from some JSON documents on the command line? JQ is the tool you’re looking for. In the previous part of this JQ and OpenAPI Series, we learned to invoke JQ and how to extract data from JSON documents using some of its many filters. Now we will discover how to build flexible and easily reusable JQ filters by creating functions and modules and also using command line arguments.

Ever wanted to quickly find, extract or modify data coming from some JSON documents on the command line? JQ is the tool you’re looking for. In this 4 parts post series, you’ll discover why and how I use JQ with OpenAPI Specification files. But more important, you’ll get some basic and more advanced example of how to use JQ on any JSON document to get and modify JSON data as you want. In this first part we’ll focus on what is JQ, why I use it with OpenAPI files and we’ll learn how to invoke JQ and discover some of the many JQ filters that can be used to extract data from JSON.

I had the pleasure to chat with Tom Johnson for his I’d Rather Be Writing Podcast. We talked about my book, The Design of Web APIs, and specifically best practices for designing web APIs and focus on the roles technical writers can play.

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 …