It doesn’t matter how APIs are organized, in layers, by business domain or any other dimension if you don’t take care of the most important one. The one dimension that rules them all: ownership. This post is the third and last of the “3 dimensions to consider for a successful API-First strategy” series.

When using Postman, it’s a best practice to store API token values in environment secret variables. Environment variables can also be used to store other variables uses in scripts. But when opening a collection, we often forget to select an environment and spend a few seconds if not minutes or more trying to figure out what the problem is with a request. Just to realize in the end that we just forgot to select an environment. How can this be avoided?

People don’t want drills, they want to make holes. APIs are interfaces exposed by pieces of software, our modern tools. But it would be a terrible idea to think of APIs just as interfaces to tools. APIs must be organized around our business domains and capabilities. This post is the second of the “3 dimensions to consider for a successful API-First strategy” series.

Either for historical, organizational, or technical reasons, not all APIs are at the same level, especially in organizations that do not start their API-First journey from scratch. APIs can be organized into three different layers: system APIs, business APIs, and experience APIs. This post is the first of the “3 dimensions to consider for a successful API-First strategy” series.

We may never have a clear answer to the question “what comes first? Tools or Specifications?”. What is sure is people create tools or specifications based on their needs. Those tools and specifications, like OpenAPI, AsyncAPI, or JSON Schema, are tightly intricated. What could be done to build a healthy and profitable relationship?

As an IT member, you convinced your boss that APIs were a thing and IT department should take them seriously. Congratulations! That’s good, very good. Not only for you and your IT but for your whole organization. All you need to do now is choose an API gateway solution and you’re done… So you think. The API journey, even just at IT level, is full of pitfalls.

Why do we need API design guidelines? Why do I need this boring set of constraining rules telling me how to design APIs? Why can’t I design APIs the way I like (which is the best one by the way). What would I (and my organization) gain taking advantage of API design guidelines?

Want to learn how to hack a desktop app calling an API and learn some API design principles? This post is made for you. When I got my Elgato Key Light, my first questions were: “can I control it without using the official control center using an API?” and “is the API easy to understand and use?”. Thanks to Postman’s proxy feature, I was able to easily hack the API. But I was also able to review it in the making, and there’s some interesting API design learnings to share.

Look how trees are represented in Piet Mondrian’s paintings shown in this post’s banner. On the left they are represented in a figurative way, on the right totally abstracted. This is what we’ll discuss in this post, not figurative vs abstract painting, but raw vs processed data in API design. Choosing between raw or processed data, date of birth vs age for instance, has a direct impact on developer experience but also on provider’s.

This time, no “API blah blah blah”, this time, it’s personal. February 2022 marks a major landmark, I can’t believe I launched the API Handyman blog 7 years ago! Being 7 years old is supposed to mark the “age of reason”. Did I reached it? I think so, but it took me more than 7 years.