Net API Notes for 2021/08/04 - Issue 170
Net API Notes is a regular, hand-curated digest of impactful news and analysis for busy API practitioners. Are you reading this on the web and not subscribed yet? Sign up today and be the first to get ad-free, actionable info delivered weekly to your inbox.
Good morning, good afternoon, or good evening! Whatever the case may be, I hope you're making the most of these past few weeks. In my situation, that meant loading up a pair of ABF trailers, driving halfway across the country, and establishing roots outside of St. Paul, Minnesota. The bruises and back still aren't entirely healed, but the news doesn't stop for a boo-boo. Let's get into this latest Net API Notes.
GOOGLE'S API PROMISE
DESIGN / DOC / DEV & TEST / DEPLOY / SECURITY / MONITOR / DISCOVERY
No one wants to build on shifting sand. Yet, when it comes to APIs, we've seen many instances where API providers (Instagram, Strava ) suddenly change critical aspects of an API's design, leaving their consumers scrambling.
Google, despite its size and resources, is not immune to the behavior. They've been so ruthless/efficient at "killing" products and services over the past several years that they've inspired 3rd party sites to keep track of it all. Perpetuating the perception that any offer has an expiration date is not a great way to build trust.
It is for this reason that Google announced its "Google Enterprise API" label. New tenets govern any API that has this label. These include expectations for higher stability and requirements about how and when changes are made to them. Changes are reviewed by a centralized board of product and engineering leads. Customers receive a minimum of one year's notice of impending changes. Finally, and the burden of making migrations as effortless as possible is on Google.
From the subsequent documentation:
"These APIs aim to build on the mutual trust with our customers necessary for long-term investments," ... "We want our customers to have the assurances they need to build creative new applications on top of our best-in-class infrastructure, using our innovative services and tools."
APIs initially under the Google Enterprise API label are from Google Cloud, Google Workspace, and Google Maps platforms.
I would be interested to see if these promises become table stakes for open, public APIs in the future.
API TESTING HIERARCHY OF NEEDS
STRAT / DESIGN / DOC /
DEV & TEST / DEPLOY / SECURITY / MONITOR / DISCOVERY
Peter Thomas has less an article, and more an incredibly compelling tweet proposing "an API Testing Hierarchy of Needs. He's currently looking for feedback. If this matches your experience, let Peter know!
REBUILDING TWITTER'S PUBLIC API
STRAT / DESIGN / DOC /
DEV & TEST / DEPLOY / SECURITY /
MONITOR / DISCOVERY
In the API history book, the Twitter API saga probably comprises an entire chapter. One of the propulsive examples of "Web 2.0", Twitter was many web developers' first API 'Hello World'. As leadership and business focus changed, Twitter's API accommodations changed. Within the last few years, a developer-friendly strategy has attempted to reengage with those audiences.
Steve Cosenza covers this and more in his YouTube recording, "Rebuilding Twitter's Public API". Steve outlines goals for the Twitter platform consistent with what I've seen with other mature efforts. Those goals include commitments to:
The talk goes into depth on how they facilitate team contributions to the platform, in terms of resource fields and selections. Steve also gives insights into how they use GraphQL fragments as part of their component-based architecture. Great food for thought.
Hey, hey, HEY! Everybody's favorite Higginbotham is now available to order! That's right, Mr. Launchany, James Higginbotham, is leading "Collaborative Web API Design". Earlier this year, I had the luck to review James's upcoming book, Principles of Web API Design. James takes his vast and varied industry experience and channels it into a pragmatic approach for better API designs in that book. If you want to search the world over for the perfect design approach, you're welcome to it. If you'd instead leverage someone else's learning to return to what you do best, sooner, James's work is what you're looking for. Whether via a book or this workshop, I'm excited to see others have the opportunity to learn from James as I have.
IBM is trying to patent policy enforcement by an API Gateway on GraphQL queries. There would seem to be enough prior art to invalidate any novelty of this claim. Spotted by Mark Boyd.
Stytch, an API-first passwordless authentication platform, raises $30 million.
Watching security researcher Troy Hunt navigate the world of IoT this past year has been as fascinating as it has been disheartening. He recently blogged about the mess, stating that the smart home won't become a thing until "devices... enable local control via a baseline set of APIs that remain stable". Hear, hear.
API Deck announced Portman, a tool that transforms OpenAPI descriptions into Postman collections and test suites.
The University of California released a new developer portal "intended to simplify the sharing and discovery of campus APIs and web services while also providing a campuswide API governance program". A good example to learn from.
August is usually a slow month for API-related events. However, I do see a seasonal uptick in events coming up this fall. The Covid-delta variant means that in-person meetings still are not a lock. However, many of the gatherings listed on Net API Events have an online component. Check it out, and if you see something that should be included, let me know.
Finally, all this edition's gratitude goes out to my Patreons. Your help ensures that this newsletter is free of advertising, information selling, or paywalls. The community benefits from your generosity.
Till next time, Matthew
@libel_vox and matthewreinbold.com
While I work at Postman, creators of the upcoming, astronaut-themed, API graphic novel, the opinions presented above are mine.