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.
NOTES
RECAPPING NOTABLE API WORLD DECKS
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.
IDEMPOTENCY AND SAFETY IN API DESIGN
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".
API LABELING?
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.
MILESTONES
- As I mentioned, 'open' APIs, or those APIs that companies release for any external 3rd party entity to build upon, have had a rough year. Mark O'Neill, a Gartner Analyst, tweeted about how public web APIs are descending into a trough of disillusionment. We're past the days of "we'll be the AWS of [insert_your_industry_here]".
- To add to the FUD, there is an interesting twitter thread by DevOps Author, Gene Kim. He (correctly) observes that patching is extremely difficult given the numerous breaking changes in dependency library APIs. The thread leads to research by Laerte Xavier on the frequency of API changes. These aren't web APIs, but code APIs. However, I think the conclusion are sobering: dependencies need to be managed very carefully, even before considering (the security concerns.
- Speaking of security, I'll end with a quick bit from the API news powerhouse that is Buzzfeed News. Grindr, which got in trouble this past April for sharing HIV status of its users with external companies, is back in the news. Nicole Nguyen reports how the mobile social networking app leaks sensitive location information through its API. This API should be private to the application. It remains unclear how external entities are able to get continued access the API (and the endangering information).
WRAPPING UP
Lots of great events throughout the end of this year are listed on webapi.events. Do you have an event that should be listed there? Just let me know via an email: hello@matthewreinbold.com.
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