By Matthew Reinbold in Newsletter — Apr 1, 2021

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.

NOTES

HOW TO WORKSHOP AN API

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 ON WHEN TO USE MICROSERVICES (AND WHEN NOT TO!)

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.

SEVEN WAYS TO BLOW API OWNERSHIP

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.

MILESTONES

WRAPPING UP

I just added the 2021 ASC conference to NetAPI.events. 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:

I chatted with the Toro Cloud folks about API Governance, digital transformation, and the people bits in-between.
Next, I discussed Pace Layer Theory and how it relates to technology change on the API storytellers vlog. (I've presented and waxed prophetic on Pace Layering in the past; it remains an effective mental model for me.)
Finally, Erik Wilde tried to bait me into a GraphQL tizzy over on his 'Getting APIs to Work' channel, but I think I managed to avoid that minefield.

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 matthewreinbold.com