Net API Notes for 2020/06/03 - Issue 132

I hope you and yours are safe, healthy, and able to find what Mihaly Csikszentmihalyi refers to as "flow" during this time, even if only for a bit. It is clear that a "return to normal" isn't an option, as "normal" wasn't working for a significant number of people. As Gerald Weinberg, author and teacher of the psychology and anthropology of computer software development said:

"A crisis is the end of an illusion."

There's something emergent afoot.

Switching gears, I'd like to share a thank you with all the folks that voted in the first round of the API BRACKET of IMPACT. It was fun to see people's reactions. I've included more details under 'Wrapping Up'. However, if you would like to skip to voting on the second round, then the Sweet Sixteen is now live.



Phil Sturgeon's time at WeWork "gifted" him a gaggle of stories, not the least of which was how to align the API work that had grown "organically". He captured his thoughts about what he found, and how he subsequently fixed it, in his piece entitled "Refactoring an Entire API Ecosystem".

What do you do when there is little consistency in versioning, no standard for data or error formats, everyone authenticates differently, and there are unreliable response times? Phil outlines four significant steps that he undertook to wrestle control out of the chaos:

  • Document the existing mess
  • Stem the Bleed
  • Drain the swamp
  • create a style guide


GraphQL is, increasingly, used in production systems. Because of this, we're starting to have a better understanding of the patterns where things can be exploited.

Carve Systems, a boutique cybersecurity firm, published "The Five Most Common GraphQL Security Vulnerabilities". The five most common areas include:

  • Inconsistent Authorization Checks
  • REST Proxies Allowing Attacks on Underlying APIs
  • Missing Validation of Custom Scalars
  • Failure to Appropriately Rate-Limit
  • Exposure of Non-Public Information Under Introspection

If you have a GraphQL API, take the lessons from this piece and apply them to your own work.


There are scads of articles across the net on the mechanics of creating APIs. But how does one continue the momentum beyond an initial release? Claire Barrett shares a number of lesser-known tips in her post on driving adoption of an API program.

Claire identifies three different groups that are necessary for success: sponsors, transformers, and technologists. I also appreciate the part about building a healthy tension. If you are a technical leader and looking to curry additional favor in your organization, check it out.



Round 2 of the API Bracket of Impact

The first round of the Bracket of API Impact has concluded! Like a sportsball tournament, many of the highest seated items (microservices, OpenAPI, etc.) breezed on through to the next round.

However, there were some surprises. In a close one, the 17th-seated "API Management" beat out number 16 "Event-Driven Services". The 23rd seated "APIs-as-Product" defeated the 10th seated "hypermedia". And in a real eye-opener, the 30th seeded Internet of Things, or "IOT", upset the 3rd seated "service mesh".

It just goes to show that even though concepts, like "service mesh", have burnt a ton of pixels as the next big thing, there are far few people impacted by them (yet).

The second round of voting runs through Monday evening. There are all sorts of intriguing match-ups. Like before, the polls can be found on Twitter.

In other news, APIDays has created a new online conference event. Called "Interface", it is June 30th and July 1st. Registration is free. You can find more information at

I've updated with the info. If you know of an upcoming API-related community gathering that isn't listed, I want to know! I'd be glad to document 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.