REST API Notes for 2018/06/27 - Austin API Summit Recap
I hope everyone transitioned easily into their summer routines. For me, that meant enjoying the excellent Nordic APIs Austin Summit before diving headfirst into a variety of new projects (while trying to watch a World Cup game or two).
How 'bout that conference?
NORDIC APIS RECAP
Bill Doerrfeld, who writes for the Nordic API site, posted his summit recap. Bill does a broad review of notable speakers and topics. Personally, I appreciated the smaller conference size - the event felt more intimate and the hallway conversations more personal, like a throwback to the 'early days' when it was a close circle of true believers sharing the joy of realizing they weren't alone in trying to execute this awesome thing.
What wasn't a throwback was the maturity of subject matter. Long gone are the days of arguing over architectural patterns or push-button 'hello world' demos. It's less about the technology and more about the business. Many of the presenters were talking, in some form, about productization and documentation.
My frequent collaborator, James Higginbotham, presented "Are REST APIs Still Relevant Today?". Clickbait title aside, he did a great job of illustrating where the industry has been and how good ideas never really die - they just come back as gRPC (I kid, I kid - for a network recording of the presentation he did for Capital One, register at https://capital.one/2lhvBOH to view). [As an aside to the aside, did you see that Dave Winer has rebooted XML-RPC, the predecessor to SOAP? I had to do a quick refresher on the basics. As much as I like to dump on all the problems with the approach that the REST style addresses, for now, I'll just say everything old is new again].
Another conference thing worth highlighting was buried toward the end of Adam DuVander's talk. He mentioned that fact that his company, Zapier, integrates with thousands of APIs. As a result, they not only have fascinating uptime information, but they publish it for everyone's benefit. Awesome.
Let's switch gears to the non-Austin info.
OPENAPI AND DESIGN FIRST PRINCIPLES
Lukas Rosenstock has an important piece on OpenAPI and Design-First Principles. I still, occasionally, encounter a developer who argues that code should be the sole source of truth in a system, and documentation should be generated from it. What I'm supplementing my argument with is a powerful insight from Lukas: the ease of generation **after the fact* tempts developers from thinking carefully about the design of their API upfront*. Agile development isn't the absence of any planning. Taking time to carefully consider usage, stakeholders, and roadmap is time well spent, even for 'internal' APIs.
A design-first approach is also mentioned in a video released by Postman. It starts by documenting the API, and then proceeds through a hypothetical API lifecycle. API-design-first (or even OpenAPI) isn't only about rendering "some documentation". It is about enabling the automation of an entire toolchain. While that can be done in a number of different ways, the Postman video provides an entertaining overview.
DANIEL BRYANT REVIEWING SERVICE MESH BASICS
Speaking of entertaining overviews, perennial favorite Daniel Bryant has written a detailed overview of containers and service meshes. He demystifies Lyft's Envoy, one of the earliest entries to managing the complexities of microservice deployment to the cloud. He also does the hard work of putting things into context of why this stuff is valuable and how it might be used:
"Maintaining reliability and high-availability of distributed web-based applications was a core challenge for large-scale organizations. Solutions to the challenges frequently included either multiple or partial implementations of retry logic, timeouts, rate limiting and circuit-breaking. Many custom and open source solutions used a language-specific (and potentially even framework-specific) solution that meant engineers inadvertently locked themselves into a technology stack “essentially forever.” Klein and his team at Lyft thought there must be a better way. Ultimately, the Envoy proxy project was created to be this better way."
Well worth your time.
MILESTONES
- The "Open API" initiative has lost the space between Open and API! It was always confusing having the foundation referred to as "The Open API Initiative" and the specification called "OpenAPI" (especially since many were still confused on the difference between Swagger and OpenAPI). But, as spotted by the API Handyman, the foundation has moved to reconcile the names. Confirmed by Darrel Miller, the Business Governing board has been updating the technical and business content to reflect the change.
- Twitter buys 'trust and safety as a service' startup Smyte, and immediately shuttered its API, leaving Smyte's users wondering what happened. Changes in strategy after acquisition are not surprising. But the lack of warning for those with existing contracts, some spanning years, is. Smyte's customers included Indiegogo, GoFundMe, and TaskRabbit, among others, who used Smyte to combat fraud, abuse and harassment; not a trivial thing. In the case of npm, it even lead to a production outage. Some reacted the shuttering as 'the new normal'. If so, that means developers will be even less likely to risk integrating with small players (or big, in the recent case of Instagram) for fear of suddenly being disrupted. Not good.
- Ok, this one is a bit complicated, but stay with me here. @toddmotto has a public API repo. @cdenoix and @frontstuff_iomade it searchable with algolia, available at https://www.api-search.io/. In other words, you can search for APIs from a public directory of APIs. Cool.
- Cloud Elements has a partnership with SAP. Yolo?
- "The API Product Mindset" is a new ebook from Apigee. Recommended.
- There's a JSON-LD validator in Bing Webmaster tools! (I had to look up what Bing Webmaster tools is. I guess(?) it is a free service which allows webmasters to add their websites to the Bing crawler. And the Bing Markup validator now supports JSON-LD. So if a tree falls in the forest...)
WRAPPING UP
Per usual, if you have a web api related event, I'd love to add it to webapi.events. Shoot me a message and let's talk.
I'm also trying something new. In the past, people have asked how they can show their appreciate for this little tempest in a teacup I call a newsletter. I don't take advertising and I certainly don't sell the email addresses - two practices that I believe undermine the conversation. Heaven knows I'm not in this for the money. But if folks want to defray the cost of caffeine for the early mornings and late nights, I've set up a Patreon page.
Thanks for reading, Matthew