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.

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.

The last API Strat 2016 day, after the last talk, a man living in kentucky asked me something like What is the one thing you will remember about this conference?. I answered something like People First.

People First. This is definitely what sticks in my mind after this conference.

I’m a thrilled to announce that apistylebook.com is now online. The API Stylebook aims to help API Designers to solve API design matters and build their API design guidelines by providing quick and easy access to selected and categorized resources. Read more on the API Stylebook blog.

With previous posts we have learned to produce an OpenAPI specification containing all OpenAPI specification subtleties. Some specification files may become quite large or may contain elements which could be reused in other APIs. Splitting a specification file will help to keep it maintainable by creating smaller files and also help to ensure consistency throughout APIs by sharing common elements.

Previous posts showed how to write a highly accurate description of an API interface contract with the OpenAPI specification. But an interface contract, no matter how brilliant, is nothing without some explainations. A fully documented OpenAPI specification file can provide some useful information and be used as a part of an API’s documentation.

After mastering input and output modeling like a Jedi, let’s see how we can describe API’s security with the OpenAPI specification’s.

After learning how to create an accurate data model, we continue to delve into the OpenAPI specification’s and discover how to describe tailor made API’s inputs and outputs.