Conversation with Senior Product Manager at Capital One and API Enthusiast
After a long pause in our interview series, we are back with one we are proud to present. This time, our special interviewee is Matthew Reinbold, Senior Product Manager at Capital One, an API expert IT recruiters love to hunt, and an advanced Lego enthusiast.
Matthew, it’s been 16 years since you started your career in 1999. Tell us a bit about your technical background. How did you envision the future of the web when you first entered the industry? Have any of your predictions come true?
Despite starting as a computer engineer doing embedded systems programming out of college, I rode the wave of Internet hysteria straight into a dot-com-bubble faceplant. I believed then, as I do now, in the corner stone ideas of the web: disintermediation, decentralization, remix culture, and altruistic benefit. I continue to hold out hope that efforts like Indieweb will win the day. But for every promise of the original web's intent being fulfilled, there seem to be twice as many efforts to assert Middle Age fiefdoms. I'm fearful the result is strip mining what is for short term profits rather than letting ecosystems of creativity flourish.
Your “REST API Notes” is something we like to read. 🙂 How did the idea of creating the newsletter come to your mind? Why REST APIs? What are your likes and/or hobbies other than APIs?
On any given day I look at a lot of content - RSS feeds, Twitter, Slack, email, Tumblr, YouTube, etc. And while most of it is noise, I wanted a way of highlighting the cream of the crop. If I can help people interested in quality RESTful API development save time and effort, then I'll do so. I'm already making the notes; I might as well share them.
I find RESTful APIs very compelling. A person would be hard pressed to name another software system that has achieved the kind of scale and resilience of the Internet. It is an incredible human accomplishment. The RESTful architectural style builds upon this bedrock. Sure, people make crappy designs. We stupidly fight over (largely) inconsequential items like how to version. But anyone who needs a reason for "why REST" simply has to look at a Google search result. And we're still only coming to terms with the potential that exists (media types, link relations, lifecycle management, automation powered by description formats, etc.).
When I'm not designing APIs, I build Lego. Like many, I played with Lego as a kid. However, I didn't get back into it until I was trying to figure out the properties of the stairwell at a previous employer. The stairwell led to a floor, and the floor lead to a building, and the building has lead to a city. Attempting to recreate form and function is a wonderful way to understand the stories behind our everyday spaces. My current crushes are 520 West 28th and the Hyatt Hotel in San Francisco.
APIs have contributed to the growth of many businesses, be they service providers or API consumers. How do you think they are still to give a new turn to economy?
For many, the API architectural style is a means, not an end. Whether using a RESTful interface or a carrier pigeon, a business will employ the methods necessary for furthering their business objective. They "gotta have an app" so they'll make an API to power that app. And that is fine.
Savvy companies, however, recognize APIs as not just fulfilling an immediate need. They realize that this abstraction decouples business function from the delivery means. In doing so, they are ready for what's post-app, and post-post-app. Is that IoT? Or VR? Kanyne-West-platinum-luxury cloud-containers? It doesn't matter for these companies. Their codified ability is implementation agnostic. In a changing technology and consumer landscape, this flexibility can't be understated.
What is the value of APIs for companies that implement new technology as a part of their procurement strategy? How do APIs and the implementation of new technology correlate?
As I mentioned above, a consumer of a properly designed RESTful API is writing to an interface, not an implementation. As long as the contract between the two parties doesn't change, the business maintains the ability to change languages, vendors, and even tech stacks without onerous cross-team (or cross-company) coordination.
Of course, the reality isn't that clean. Nobody is going to be swapping out their system of record every other month. But if the APIs are designed correctly, they could and the consumers would be none-the-wiser.
Say a company has decided to integrate with a system or a service. What are the things to pay attention to before the development process begins? Are there any that they can overlook?
It is tempting to throw the developers at it. "Time to First Hello World" (TTFHW) is a popular metric shared at conferences. But, for anything more than scratching an itch, there are so many additional factors that need to be considered.
What is the API provider's business model? Is there a published Service Level Agreement (SLA)? Is there a roadmap? Who directs changes? How are uptime and outages communicated? What is the deprecation strategy? Is there support, or support tiers? Are there rate limits and throttling, and what is the likelihood that business-as-usual will hit them?
I've been a developer. I know all those questions are exceedingly boring when compared to getting a CURL statement to run. But when running a business these integrations represent strategic bets. Eliminating as much risk, both technological and financial, is vital.
As an API architect and a Software Team Lead, you are a dab hand at planning and building APIs. What is the secret to writing a unified API that fit the needs of various clients who see the use of the API differently?
The secret is having empathy for your clients. That is, coincidently, one of the hardest things to get right. It means treating your API as a product. It means having an outside-in approach to API design. There are many tools that take a data model and output an API interface. But that inside-out approach is at the convenience of the API developer, not the API consumer.
What if they request incompatible features? Do you think versioning is the only way out?
Versioning should be avoided and only introduced when a breaking change is necessary. Versioning is best thought of as a resource at a moment in time - I've been twenty-something and that is not the same version of me nearing forty. I've changed. But two versions of me don't exist simultaneously.
If the features are truly incompatible, I would take a hard look at the resource design. Chances are that if these things are as disparate as pickles and peanut butter then they should be separate resources. It goes back to empathy: trying to cram ideologically opposed concepts into a single resource sounds as though it may be a convenience for the API developer, not the API consumer.
To put the finishing touch, let’s get back to envisioning the future. What are your current predictions for the future of the API economy?
We've got a long way to go in terms of API discovery, testing, management, metrics, and governance, particularly in the realm of microservices. The hype over connected things (what Bruce Sterling referred to as "Spimes" long before IoT was filling conference centers) is running headlong into security realities. I'm excited about serverless architectures actually fulfilling the promise of DevOps. I'm also looking forward to what is after OAuth 2.0 (although I'm unsure whether raising the specter of Eran Hammer's last work on the topic is a vision of the future or a ghost of the past).
A world-class DJ is able to bring the entirety of recorded history to bare in a performance. They slice and dice, layering the emotional potential into new and exciting forms. Until we are at the point when an accomplished developer can mix and match functionality to create powerful new experiences with the same ease, we've got more work to do. (For more, read Matthew's The API Economy and the Amen Break).
We want to thank Matthew Reinbold for taking the time to answer our questions. 🙂
