Net API Notes for 2021/04/02 - Issue 157

What a whirlwind week! As I blogged Monday, I'm joining Postman. Like most in the API space, I've loved Postman for years. Now I'm thrilled to be joining Kin Lane (the API Evangelist), Fran Méndez (AsyncAPI), Ben Hutton (JSON Schema), and a host of other notables to accelerate the next phase of distributed system growth.

But that wasn't the only API news this past week. Let's get to the notes.



Getting feedback on an API design early and often is the difference between a solid V1 launch and immediately pivoting, in shame, to a V2. However, in an age of social distancing and virtual everything, how do you get that kind of rich conversation going?

SAS's Adrianna Vu had a similar problem. Thankfully, not only did she overcome the pandemic challenges, but she also posted a guide to conducting virtual design workshops. Adrianna carefully walks through various available techniques that facilitate understanding, proposes several useful tools, and gets real on the time investment required.

This article is precious and in an area many don't think about.


Sam Newman and Martin Fowler are both big names in terms of microservices. Sam is currently prepping the second edition of his foundational book, Building Microservices. Martin Fowler, along with James Lewis, popularized the term and their "Characteristics of a Microservice Architecture", remains one of the top Google results.

In a GOTO Conference podcast recorded in 2020 but recently released, the two discuss when microservices make sense, when you shouldn't, and what other considerations architects and tech leads should consider before making up their minds.

The key takeaways are as follows:

  • Microservices are a means to an end; "doing microservices" for microservice sake is the wrong approach.
  • Microservices shouldn't be the default option. Start with a simple monolith topology and evolve from there.
  • Microservices enable independent deployability, isolation of data, and organizational information hiding (a key aspect for modularity).

The full transcript, for those more comfortable skimming and scanning, is also available.


API Ownership, or who can decide what in an API design, is a deceptively complex topic. The API Handyman, Arnaud Lauret, lists seven ways that incorrect API ownership can harm the API design.

The whole piece goes into great detail. However, to summarize Arnaud's points, avoid:

  • Giving a single consumer whatever they want; doing so results in an overly specified and bloated design.
  • Producing APIs by teams, rather than by holistic capability.
  • Exposing data from a source owned by others (no data backdoors!).
  • Outsourcing implementation of a first design to those who will not have to maintain it.
  • Delegating API production to those without the understanding of its business value.
  • Assuming an API Center of Excellence/Enablement/Expertise will be able to correct everything.
  • Empowering a headstrong API dictator at the expense of the morale and future growth of individual teams.



I just added the 2021 ASC conference to The annual API specification conference also announced its call for proposals (CFPs). You have until June 11th to submit your talk idea.

Also, if you have time and haven't checked them out already, I had several delightful, recorded conversations last month. In no particular order:

Finally, thank you for your attention and to the Patreons who enable this newsletter to remain ad-free! That means a lot to me. And, based on the subscription numbers, others do too!

Till next time,

Matthew @libel_vox and

Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.