REST API Notes for 2018/09/20

This has been a busy week! I've got Plenty of updates on tap in this email to clear out before APIStrat and APICity in subsequent weeks. But if you want to get things kicked off with some bounded-context humor, be sure to start with XKCD's comic on 'the Sandboxing Cycle'.

Had a good chuckle? Good. Let's jump into the notes.



API World was held in California and there were a few decks worth mentioning. The first, by Irakli Nadareishvili, is entitled 'Building Fintech with Microservices and Kubernetes. In the interest of full disclosure, a mid-year reorg made Irakli my boss at Capital One. His mention should, in no way, be construed as sucking up to the boss (unless it works, and then that's totally what this is).

Even if we worked in different companies, however, I'd highlight the piece. It has detailed breakdown of various techniques that teams can apply when designing their APIs. The deck pairs nicely with Bilgin Ibryam's InfoQ article, "Microservices in a Post-Kubernetes Era".

Redhat's Christian Posta also had a solid piece on "The Service-Mesh Landscape. What I like about this presentation is that it presents the incremental path that teams play out on their journeys to a service mesh architecture.


Kristopher Sandoval, writing at Nordic APIs, has a foundational piece on Idempotency and Safety in API Design. Creating an API that only uses a single verb, like POST, ignores the larger internet infrastructure to its own detriment. James Higginbotham, another frequent collaborator of mine, covers much of this in the section "Client-Side Caching" in his piece "The Power of HTTP for REST APIs".


Erik Wilde and Cesare Pautasso have a deck out on the importance of labeling APIs. If I understand the gist correctly, the idea is to provide a machine-parseable format for important API information; this would include things like SLAs, links to documentation, support info, etc.

I'm struck with the similarities to the APIs.json effort. However, the label proposal also mentions the possibility of external certification bodies for certain claims made (like if the API actually has 99.9% uptime, perhaps?). That's interesting but how large is the problem actually being solved here? For B2B partnerships dependent on API interactions, there is (hopefully) strong contractual assurances in place defining proper behavior (or steep financial penalties if there aren't). This, then, would seem to be more appropriate for 'open' APIs that are competing in a marketplace. But, as we've seen throughout this year (and below), the open API space has seen better days.



Lots of great events throughout the end of this year are listed on Do you have an event that should be listed there? Just let me know via an email:

Also, as before, a thank you for those that help cover the caffeine that makes the newsletter possible. You can find more information on my Patreon page.

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.