APIs Are the Connectors Between Your Company and the Outside World
APIs Are the Connectors Between Your Company and the Outside World
An interview with Mike Amundsen, Director of Architecture for the API Academy on the roles APIs play in business development and the future of APIs.
Join the DZone community and get the full member experience.Join For Free
Editor’s note: Have you ever considered the API in the context of jazz improvisation? This week we at Data2CRM.API welcome you to gain inspiration from an internationally known author and speaker, Director of Architecture for the API Academy, Mike Amundsen. In this talk, you’ll find out what role API plays in business development, get the explanation whether the perfect Application Programming Interface is the myth or reality, and catch up predictions about the future of APIs and its business value.
Mr. Amundsen, during the last 15 years you have been closely involved with web apps building and API industry, you have also authored numerous books on programming and became a guru in the niche. Could you tell us a bit about the beginning of your digital career? When did you discover your passion for APIs?
I didn’t start out as a programmer. I actually have two degrees in Music Theory and Composition. I thought I’d be a music professor but instead ended up fascinated by the early “home computers” in the 1980s and started a whole new career. I went back to university to study BASIC, COBOL, and VAX Assembler and eventually started writing assembly code for many of the early home computer chips. After several years working as programmer, I moved into software architecture and started focusing on the Web and APIs in the late 90s. I’ve been doing that ever since.
It was quite surprising to learn that you have a degree in music theory and composition. Do you use any of the musical concepts in your current work?
Yes, I do. I tend to approach systems design and APIs the way some might approach creating a musical composition. I am particularly interested in jazz and improvisation and, to me, the interplay of service APIs and independent Web client applications is much like jazz. The application – the “composition” – is influenced by who shows up, what they want to do (or play) and how each interacts with the other. The Web is very much like one big improvisation. I did a talk about this for the API Craft in Detroit in 2014 called “The Art of Hypermedia”
Now, you hold the position of Director of Architecture for the API Academy at CA Technologies. Can you tell us more about your working experience there?
The API Academy was created to focus on the principles and practices of designing, implementing and maintaining APIs — especially for those working in a private company. It’s a great team of people based around the world (Canada, US, and Britain right now) and I get to travel the world meeting amazing people working on incredible projects and help them work through challenges related to APIs. The Academy is sponsored by CA Technologies and CA is one of our biggest customers. No matter where I am in the world, I get to meet with CA teams and work with their customers, too. It’s a great job and after four years I feel honored to still be a part of the Academy.
You have been writing quite a lot about API strategy and tactics, API building and adoption, etc. In your opinion, is there such a thing as a perfect API? How would you define it?
Perfect is dangerous word, but there is definitely API design that is a “good fit” for your needs. The trick is that not everyone needs the same solution. So not everyone needs the same API design.
One of the things we talk about a lot in Academy events is the process of focusing on the problem, digging up details, and then solving the problem you have on hand. Instead of just showing up saying something like “You should use a REST API or a Hypermedia API or a Reactive API” you should really spend time working through the problem from several of points of view. That leads you to the best fit for your current needs.
Of course, a year or so from now, your needs might change and then you get to do some more digging and designing and implementing. The work of creating APIs is never done.
What are the top mistakes developers make when designing APIs? What tips would you give to young software engineers?
Well, as I mentioned, my advice is to *not* jump to conclusions or apply a single model or pattern to all the design problems you see. Roy Fielding said, “Consider how often we see software projects begin with adoption of the latest fad in architectural design, and only later discover whether or not the system requirements call for such an architecture.” That’s a common mistake to avoid.
Another common mistake is to think you design APIs just one time and leave them alone. If they are vital to the company, then the APIs will need to change over time at the same pace as the company changes. That’s why we see so much demand for faster, more agile API implementations — because the companies that need APIs are, themselves, moving faster.
So, don’t come to the party with a fixed idea of how an API will be designed and don’t expect the API you eventually implement to remain unchanged over time.
The book ‘RESTFul Web APIs’ is a “follow-on” book to Leonard Richardson’s ‘RESTful Web Services’ from 2008. The ‘RESTful Web Services’ book is, I think the best one to learn about the Create-Read-Update-Delete (CRUD) style API design pattern. Leonard and I have known each other for several years and he approached me to join him to write the RESTful Web APIs book after he read my Building Hypermedia APIs back in 2011.
The RESTful APIs book is focused on the hypermedia pattern. It covers the basics of designing hypermedia APIs and includes references to several formats and design patterns for implementing hypermedia services. Leonard is a great writer and it was a pleasure to work with him on this book.
As one of the most prominent API speakers, how would you explain the value of APIs to non-techie businessmen?
APIs are the connectors between your company and the outside world. They’re like the distribution network for your company’s goods and services. A weak distribution system limits your ability to grow the company. A strong distribution system can help you set up profitable partnerships and get your products to the right place at the right time. Whether you are a focused on end consumers (like Google or Facebook, etc) or focused on B2B-style services (like AWS or Microsoft) you need great APIs to make it all work.
And the more effective and efficient your APIs, the more profitable your business can be.
You have presented an amazing talk on the topic of “Liberating the API Economy with Scale-Free Networks”. Could you elaborate a bit on the term “API Economy”, how do you see it developing in the future?
The API Economy is just what we were talking about a minute ago — the distribution system of today. In the past our model for distribution was tied to physical limits like distance and time-to-delivery, fuel costs, availability of the product, and so forth. The API Economy is not limited in this way. Distance and time mean almost nothing on the Internet. And often the delivery cost is eventually zero – especially if you are delivering multiple copies of the same thing like music or software programs. So the rules are different, too.
In that talk, I tried to get people to think about how the Internet is organized – as a special kind of network called “scale-free network” where the value is in the *connections* themselves. Identifying strong connections is how Google made its billions. And anyone can do that, too. They just need to focus on the connections, not just the data that passes along the way.
Are there any API developer tools or useful resources that you use and would be willing to recommend to our readers?
I’m a rather simple person when it comes to tools – I use VIM or plain editing tools, lots of command line interfaces on Linux and hand-write most of my application infrastructure. I don’t I don’t use many frameworks or libraries when I write code.
And I read constantly. I think I have three or four books started right now and complete one or two a week sometimes. Reading is my primary resource for ideas and thinking about challenges. I usually share what I am reading via Twitter and Google+. I also published my recommended reading list for API developers on InfoQ back in 2014. It might be a bit out of date, but I think that’s still a great set of resources for anyone working with APIs.
To put the finishing touch, could you share your predictions about the future of APIs and its business value? Do you think their role will change in the upcoming years?
I am fascinated by the shift in the last year or so back to the details of designing and implementing service components for APIs. They’re called “microservices” now and I think the move to making services smaller is a good one. I think the AWS Lambda project is a great example of this idea. Essentially, AWS makes it possible to write code and not think at all about any of the infrastructure like server hardware, operating system, or even network protocol. That’s a small service!
So, just as AWS has disrupted the business of hosting your own hardware, they’re attacking the problem of provisioning your own software with this Lambda approach. And I think this kind of thinking can disrupt other areas, too.
One place that might happen is in the orchestration space. We have lots of expensive and complicated tools for orchestrating component interaction. I think services like IFFT and Zapier have the potential to completely disrupt the business of orchestration by replacing it with a much cheaper and simpler “when” model – “When a message comes in with X in it, do Y”
I also think we need to change the way we think about and create software in general. I see way too much code today – much more than I used to see and I don’t think that’s good. Mel Conway says “typing is an unnatural act” and he wants to change the way we build programs by using simple construction metaphors. His #HumanizeTheCraft project looks to me similar to the way Alan Kay’s Squeak looks. And these ideas are not new. Both Conway and Kay were there in the earliest days of mainframe and personal computing.
So, maybe the future of APIs can be found in the ideas of the past? That’d be pretty interesting, I think.
Mike thank you so much for this valuable input and inspiring information about API concept.
Opinions expressed by DZone contributors are their own.