REST API Notes for 2018-02-21

Having lived on the east coast for the past several years, traveling to the west coast always messes me up. It is only a three hour difference. Yet, here I am, up at 6am Pacific and feeling like I'm already behind. I, honestly, don't know how folks deal. But if that cattle prod of anxiety is what drives me to get a newsletter out, so be it.


Mike Amundsen, a featured regular, usually lets his presentations do the talking. However, he recently broke his blog silence. Did he talk about service meshes? Maybe GRPC/protobuffs? Metaphor-to-deck synaptic interfaces?

Nope. In Model Actions, Not Data, Mike (correctly) points how all too many people are still mentally mapping CRUD actions to HTTP verbs, turning their db design into their resource design, and then wondering why they end up with poor DX. It never hurts to revisit base assumptions with the benefit of hindsight. Mike's piece collects some of the best thinking on the subject in one place.

Sound design principles remain good ideas regardless of the tools, languages, and/or frameworks (case in point, check out this ACM article from 2007 that the API Handyman re-discovered; it is about language APIs, but it might as well be about today's web APIs). While there might be some exasperation Mike is expressing between the lines, periodic reminders of these fundamental tenants are necessary.


Microservices' complexity means that getting a handle around the performance can be difficult. In The Red Method for Monitoring Microservices, Tom Wilkie defines a different approach for performance metrics.

An interesting wrinkle is that the Red Method allows engineers to be "on call for services they didn't write". If you're a DevOps devotee, that last statement might furrow a brow. But what companies have discovered, with the 'you build it, you support it' model, is that complex, multi-faceted deployments result in a lot of folks tethered to a phone.

Is this how microservices will be supported in the future? I love to hear from anyone that has adopted this model about what their experiences have been.


Speaking of microservices, Jimmy Bogard captured a whole heapingful of his microservice knowledge in one spot, entitled My Microservices FAQ. It is a nice, concise reference that, hopefully, finally answers the question of "how big should a microservice be?".


This week, there were a host of free references available for folks looking to add to their (digital) bookshelf.


Some fine folks have been emailing me their events. I've since added them to Do you have something? Either respond to this note directly or send me an email at ''.

Also, do you know of someone with API technical documentation experience who would be interested in working with the Capital One team? We're hiring. Give the job listing a look.

Til next time,


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