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?


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


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.


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.



Per usual, if you have a web api related event, I'd love to add it to 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

@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.