Net API Notes for 2020/06/26 - Issue 135

A co-worker just shared this on our company Slack yesterday:

"An API service that my husband's company depends on just sent them an email earlier today that said 'we are updating our API endpoints today at 3 pm. Please change all your calls to this new service to prevent any loss of functionality.' This was the only email they have ever received about API changes... People still do this $%*@?!"

Unfortunately, yes. After years of exposure to the software-hype machine, one might think that the latest micro-mesh Kubernetes event-driven gee-gaw was the difference between API success and failure. Innovation does happen. However, it is continued execution on the basics - minimizing surprises and doing the intricate work of keeping things simple - that can't be overlooked.

Said another way, if you're wringing your hands over what service mesh provider to choose but haven't established a well-understood and customer-responsible sunset process, you're focusing on the wrong thing.

In evaluating the content for inclusion in the newsletter, sometimes I ask myself whether something is too introductory or beginner. However, seeing behavior like that above, I'm reminded that we would all benefit from an occasional refresher.



I have an update on the 2020 Big Bracket of API Impact below, under 'Wrapping Up'. One of the comments that I got, more than once, was, "Where is API security?"

I briefly thought it would be funny to let the polling run its course clear through the finals and then have the event "hacked", thus emphasizing the importance of security above all. But it seemed an overly-elaborate gag that only a handful of folks would appreciate.

There was a poorly-written security piece circulating this past week. After careful consideration, the most useful aspect was the mention of The OWASP list of Top 10 API Security Vulnerabilities. The best time to address those issues was during the first implementation. The second best time is now.


Don't let the title fool you; Scott Middleton's "Are You Going API Crazy is not another microservice-to-monolith rant. Instead, it is a nuanced explanation of how Jobs-to-be-Done can be used to create better API designs.


Jobs-to-be-Done is only one tool for exploring your API space. A popular, more recent, technique is Event Storming. Despite being newer, event storming shares at least one characteristic with what has come before: you get out what you put in.

Nick Tune has a piece entitled "EventStorming Modelling Patterns: Going Beyond the Superficial".

"With so many benefits, and such an apparently simple technique of scattering orange post-its all over your biggest walls, people often end up surprised and disappointed when their EventStorming sessions don't result in hundreds of groundbreaking insights. They feel like their time was wasted and it is not something that suits them.

"In my experience, the people who feel their time is wasted with EventStorming are those who don't understand the benefits and how to achieve those benefits. They model only at a superficial level."

How does one avoid modeling at a superficial level? Nick goes into detail on fourteen(!) different principles to make your next session as meaningful as possible. Definitely, worth a look.




We're here! We've arrived at the final of the 2020 Big Bracket of API Impact! We started with 32 of the most common API trends, techniques, and technologies of recent years. Now we're down to two! It's API Design-First verses Swagger/OpenAPI. Who will win? It is up to you to decide. Vote now on Twitter.


In other news, I'm adding folks to my team at the day job. I'm looking for generalists, big-picture thinkers, and change agents. I characterize the opportunity this way:

"It is a unique role that combines internal developer relations, architecture, strategy, and organizational development. Your work impacts the entire organization as well as the host of financial institutions that use our APIs, event streams, and data. My team understands that empowering, equitable software ecosystems are more than gates and checklists. We build the kinds of governance processes and sociotechnical safety to continue a tradition of innovation. If you've worked on technical standards before, used your influence to drive digital transformation, or call yourself an architectural change agent I want to talk to you. This is some of the most challenging, yet rewarding, work that multi-disciplinary folk can apply their whole selves to."

If that resonates with you, I'd love to talk. Send me and email with where you are currently at and what you're interested in doing and we'll go from there.


The virtual API Days Interface conference is next week. It the fact it was free wasn't enough, I'll also be speaking! (Insert your own 'you get what you pay for' jokes here.) My talk is "APIs are Arrangements of Power. Now what?". The abstract is:

"Whether they know it or not, companies are responsible for dozens, if not hundreds of APIs. The organization of these APIs includes decisions on boundary ownership, access, and continued investment. These enforced relationships are arrangements of power.

"Delivering useful software requires the navigation of these, sometimes tricky, arrangements. Companies often attempt process solutions rather than tackling the real issue: their organizational structure. In this talk, Matthew demonstrates how to identify, mitigate, and continuously evolve beyond organic or ad-hoc arrangements to deliver impactful, long-lasting API designs. For leaders, future leaders, and those balancing system coherence and ecosystem variety."

Is it for everyone? No. But if you've ever been around more than a handful of APIs and wondered how everything became a tangled mess, this is the presentation for you.

NET API NOTES has the events, online and off, for the API community. That includes this fall's API Specs Conference (or ASC). If you know of an upcoming API-related community gathering that isn't listed, shoot me an email! I'd be glad to add it.

Lastly, thank you to the Patreons who support this newsletter.

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.