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.

This is the end, my OpenAPI friends, the end. The end? Not really. This last part of the OpenAPI tutorial is a new beginning. With previous parts we have learned to master the OpenAPI specification but there’s a last thing to learn to unleash its full power: extensions. This format is easily extensible, it allows to add custom data within an API description. But for what purposes? Let’s have a glimpse of these extensions endless possibilities.

GraphQL is new. GraphQL is cool. Look! Github dumped REST for it! We MUST do it too!
Well, why not. GraphQL could be a great tool, but like any tool, you don’t choose it just because. You choose it because it solves a problem in a given context. You choose it knowing its strengths and weaknesses.

While discovering what is GraphQL we will see what REST API providers should think about before blindly dumping REST for it. From design and implementation to pricing model and analytics down to developers experience and implementations, choosing an API design style will have impact on the whole API lifecycle. Therefore, this choice must be an enligthned one and not based on simple beliefs.

ICYMI, I’ve just switched from a self hosted Wordpress to a Jekyll static website hosted on Github. The code is available in the apihandyman.io repository. If you’re looking for information and tips about how to enable pagination on categories pages and have infinite scroll with Jekyll or how to to deploy a Jekyll website using custom plugins on Github Pages, you should take a look at it.

If you wonder how to evolve a company’s IS in the lego computing age, read my post on Nordic APIs blog.

OpenAPI offers many possibilities that span the full API lifecycle, yet it is seen purely as a solution for generating API documentation. This session will tell the story of AXA Banque's evolution from .doc and .pdf API documentation to the extensive use of OpenAPI Specification (formerly Swagger). Throughout the journey, we will identify the many advantages of API definition languages beyond simply generating API documentation, including design, testing, documentation continuous delivery, code generation, mocking, and prototyping new ideas.

Just before the Developing an API Strategy for 2017 panel, I have been interviewed about Swagger/OpenAPI specification and the API Stylebook by Keshav Vasudevan from Smartbear.

Shortly before API Strat, I have participated to an API experts panel on Developing an API Strategy for 2017 organized by Smartbear with Laura Heritage, Matt Bernier, Ole Lensmar and Tony Tam hosted by John Purcell.