Today is just that day to continue our API-expert-interview series. This time we are proud to present our talk with Mike Stowe, a Developer Relations Manager at MuleSoft who knows everything about APIs and their design. You can also know him as an actor and just a great guy who can make your day.
In this interview, he reveals some of his priceless career memories, talks about his book on API design coming out soon and points out some common developer mistakes.
First of all, happy birthday, Mike! API2Cart team wants to wish you many more years of productive work, success, and awesomeness! 🙂
You are a true professional in the sphere of software engineering and have dedicated more than 10 years of your life to work. Are there any special or funny moments to share?
The great thing about being in the developer community is that life is full of special, and funny moments. In fact, I’m sure that those that know me have several they’re more than willing to share. But, the one memory that really sticks out is that of my first days at CaringBridge. I had the chance to work for an incredibly talented individual named Mike Willbanks who I have to say was a tremendous manager.
Eager to prove myself, I quickly flew through the first project he gave me and pushed my code. Mike, my boss, then got up and walked over to my desk, asking me if that was my commitment. Feeling super confident, I looked at him with a beaming smile, gave two thumbs up, and said, “you know it.” Without missing a beat, he just looked at me and stated somberly, “You’re an idiot.”
Now, the truth is, I was – my code was horrible!!! I rushed through, I didn’t take advantage of best practices, and I had a lot to learn. Thankfully, Mike and the other awesome members were kind of enough to teach me… But that was the day I was reminded that you ALWAYS have things to learn and that you always need to work to continue growing. And that’s a lesson I am tremendously thankful for.
It seems like you were born a programmer, weren’t you? 🙂 When did you discover your interest in technology and APIs in particular?
In a way, I guess I was. But it wasn’t a straightforward path.
My first experience with technology was when my father brought home a Macintosh Color Classic that he used for work, the same machine my oldest brother started his company on. I was absolutely fascinated with it, watching them work, seeing what it could do – but while I loved technology I still didn’t have any concept or interest in programming. In 7th grade, however, I suffered an injury that kept me from playing the sport I loved, basketball. Suddenly, I had a whole bunch of free time, and started playing around with this service called HotYellow98 (think Geocities only more basic) – creating a free website (wayyy before it was the cool thing to do). Learning something called HTML was eye-opening to me, as I was able to create things with a few words here and there, and the more I did, the more possibilities were unlocked. For my birthday my mother took me to the bookstore where I picked out my first programming book (PHP), and in 8th grade I even wrote a letter to myself saying how I was going to be a programmer (I was kind of a dork).
But things shifted, and instead of programming, I went to school to be a nurse – with the hopes of becoming a life-flight paramedic. As it turns out, that wasn’t in the cards for me, and while trying to figure out what to do with my life I kept programming (as a hobby), until one day someone heard about some of the projects I had done and offered me a job. Again, I knew very little about programming other than what I had taught myself, but because of the amazing community, and because I absolutely loved learning new things, I was able to keep growing. I think that’s why community is so important to me, because without it, I wouldn’t be able to be doing what I love. I was very blessed that people gave me a chance, and were patient enough to help me grow.
As for APIs, that’s a fascinating topic for me, as I’ve been using them for years without ever really thinking about them. They made for a great tool that allowed me to extend my applications- such as bringing in services like directions and weather to a disaster resource management tool that I was working on. But outside of that, I never really thought about their potential, at least not initially.
I think what really peaked my interest into designing and building APIs, was the recent explosion of APIs, the numerous methodologies and debates (everyone had a different opinion) – and all of the horrible APIs I started having to have to use as a developer. I really wanted to understand what made a “good” API, and why people were having these debates about “what is RESTful” or whether or not to use SOAP.
It really started as a quest for my own understanding, and so that when I built APIs I wouldn’t be causing other developers the same anger and frustration I was experiencing.
It is no secret that you are a willing conference speaker. What seminars would you recommend our readers as must-see ones? Were any of them dedicated to APIs?
Giving back to the community is incredibly important to me, and I’ve been very blessed to be able to try and share some of my learnings at some different events. About two years ago, I had the chance to give a talk on building an API with Zend Framework 2, and during the talk it occurred to me that building an API is actually pretty easy, but there was a lot of misunderstanding in how to design a good API.
After giving the Building an API with ZF2 talk, my next talk was API Best Practices, and then learning about RAML a talk on that, followed by my API Strat 18 Best Practices talk, a talk on Building Your API for Longevity, and most recently a talk focusing on Hypermedia (the good, the bad, and the ugly).
Whenever possible, I try to share the slides and videos of these talks on my own site, at https://www.mikestowe.com, as again the purpose of these is to try and help others grow in their field and understanding, just as so many people have helped me.
You have a book on API design coming out soon. When and how did the idea of writing the book come to your mind? Is there a story connected with it or the title?
Writing a book has been something I’ve wanted to do for years, and I can’t tell you how many times I’ve started writing a book but never finished!!! The idea for this book came from the responses to my presentations, as well as my API Best Practices series, and really focuses on the things I think we as developers have a hard time doing – going back to the basics.
For example, a lot of people are talking about REST, but do we really understand the constraints of a Representational State Transfer design? Do we understand why we should (or shouldn’t) be using REST instead of RPC or SOAP? Do we understand what hypermedia is and how to implement it?
I really believe that before you can build something well, you need to understand what it is that you’re building.
It’s my hope that this book is able to give developers a strong foundation for understanding what they are building, and knowing what the standard best practices are. Not just so that they can be successful, but also so that the developers who are trying to use their API can be successful and have the best experience possible.
Could you tell us more about the content? What are the points that will surely grab the attention of developers? Are there any new methods described in the book?
Being that you need to understand what it is that you’re building before you build it, the book starts off with a quick introduction to what APIs are, as well as the different types of Web APIs out there, quickly skimming over the strengths and weaknesses of each. We also take a hard look at what REST is (and isn’t) focusing on Fielding’s primary constraints, as well as looking at questions the developer should be asking before even choosing what type of API to build.
Once we get through the initial planning stage, we take a look at designing your API with Spec Driven Development, the different specs out, and Prototyping/ Soliciting feedback for your API design.
The next section of the book focuses on best practices, taking a look at authorization, designing your resources, designing your methods, and implementing hypermedia. But I wanted to take a real look at hypermedia, focusing on what it is in hopefully a relatable way, what this concept of “Hypermedia as the Engine of Application State” is, what specs are currently out there to help you, and what the challenges of hypermedia are - especially with the limited implementations that we have in today’s APIs.
Finally, if somehow the reader isn’t completely bored or using the book for firewood, we’ll take a look at managing and documenting your API, focusing on what developers are looking for, who’s doing it right, and what tools are out there to make it easier.
I think that pretty much sums up the book, although I am sure I’m missing some of the topics covered. There’s a lot more we could be talking about, but hopefully, it provides a good starting point and helps people avoid some of the painful lessons I’ve learned working with and building APIs over the years.
And to do a shameless plug, if you follow me on Twitter: @mikegstowe, I’ll be announcing the book when it’s released, as well as a link for a free download.
What are the top mistakes developers make when designing APIs? What tips would you give to young software engineers?
I think the three biggest mistakes I see being made is first not understanding what it is that they’re building – a lot of developers are quick to build a “REST API” without first reading and taking time to understand Fielding’s dissertation, or even to reach out and interact with their potential users.
I think the second is trying to build an API without first designing it, and testing that design. Fielding, on his blog Untangled, points out that we are usually very good at short-term design, but often awful at long-term design. And APIs are generally designed for the long-term- that means thinking beyond just this and the next release.
Lastly, as a developer I struggle with Shiny Object Syndrome (SOS) – I want to build the latest and greatest thing, using the latest (and often untested) technologies. The problem again is that we oftentimes don’t think through the possible repercussions, and instead get “tunnel vision” into what it is that we’re building. We also forget that we’re not building an API for us, but for our users, and that means we need to keep it as simple and succinct as possible.
That isn’t to say that we shouldn’t be innovating, quite the opposite, just rather we need to be careful to keep a clear line between trying new things out in our personal side projects, and putting untested technologies/ concepts into production.
Are there any API developer online tools that you use and would be willing to share? We are sure that programmers will appreciate your advice.
When I interviewed with MuleSoft they were telling me about an open-source initiative, RAML, that they were supporting. I can’t tell you how skeptical I was about it, as every company brags about the tools and technologies they back. But soon after looking at it, I was writing a blog post with a One Direction song professing my love to RAML.
RAML or the RESTful API Modeling Language completely changes the way we build APIs, bringing them into the modern age of development techniques – including the ability to visually see what it is we are building as we design it, and to quickly prototype an API and get user feedback – something that would previously take weeks to months and require substantial amounts of code rework.
RAML is also backed by an open source community, providing even more tools for quickly generating documentation, SDKs, and even providing an interactive playground or lab for developers to try working with your and other APIs using basic JavaScript.
This playground, the API Notebook, even lets them create their own use cases and scenarios, meaning that when something goes wrong they can send you back a reproducible sample (perhaps the greatest thing ever) without having to share ANY of their own code.
RAML is really the foundation for Spec Driven Development – which again I think not only changes the way we build APIs, but helps us design APIs that are carefully thought-out, meet our client’s needs, adhere to best practices, and are more flexible and long-lived. In essence, it’s my belief that by using Spec Driven Development to it’s fullest, we can eliminate or at least greatly reduce the impact of our tendencies to design for the short-term.
And the last question for today. What are your predictions concerning API evolution in the future?
I think the first thing we have to realize is that Web APIs, especially in the way that we know them today, are still pretty new. In just a very short time, APIs have changed the world, with more reliance on connected technologies happening every single day.
Because of this fairly rapid transition, most companies, and even developers are still grasping with how to utilize APIs efficiently, and even understanding what concepts like REST are. For example, we’re quick to highlight REST as an HTTP API, but REST is an architectural design theory and is not constrained to the Hypertext Transfer Protocol.
As such, I think we’ll find more and more emphasis on RESTful APIs outside of HTTP, especially for device-to-device transmission.
The next area I think we’ll see drastic advancement in is with hypermedia, as personally I believe we are still not using it to its fullest capabilities, especially within REST HTTP APIs. What that will look like, I’m not entirely sure, but I think we need to look beyond the current specs that are extremely limiting and fairly inflexible, and look more towards hypermedia through the lens of HTML.
I think we’ll also see more utilization and reliance on code-on-demand, the only optional constraint of Fielding’s REST. One of the greatest challenges we have with APIs, even with hypermedia is breaking backward compatibility. My guess is you’ll see this first implemented into SDKs, but eventually, in API responses themselves (CPHL serves as an example of this). Before we get to that point, there are a lot of hurdles that we still need to clear, including security, but I think there are ways we can start taking advantage of it today. It’s just figuring out how to take advantage of it, even more, tomorrow, and the day after.
Lastly, I’m excited to see what happens with HTTP/2. I’m still looking into this myself, but I’m especially excited about the addition of server push technologies, and the collaboration between client/ servers that could bring with it. Of course, speed is also critical when utilizing an API, and HTTP/2 brings with it header compression along with the ability to make parallel or asynchronous calls across different hosts. I think this really expands the capabilities and use-cases for APIs, and I’m curious to see how much things will change as these new features become more commonplace.
We want to thank Mike Stowe for finding time to give such sincere and detailed answers. 🙂
And do not hesitate to contact us if you are a developer wanting to ease the donkey work of eCommerce integration. To do this, schedule a FREE call with our representative.
