3 Big API Trends: My Nordic API Summit Trip Report

by Ken Tabor

Photo credit: Sophi Marass

I attended the Nordic API Summit in Austin this June. It was focused on a cool tech topic that we considered over a few hot Texas Summer days. We gathered together at the Palmer Events Center to escape the heat while exchanging best-practices and pro-tips regarding everything about APIs.

API stands for application programming interface. I refer to them as the digital tools that programmers use when building their applications. If your company does something well, and it was difficult to do, then you can create APIs to make it easier for others to do that thing well too.

Making APIs is one way to create more value in the marketplace, and share in the revenue.

There to Listen, and to Speak

We were glad to attend this event. Even more exciting, my colleague, Julian Macagno, and I were on the agenda as speakers. Submitting a talk idea and getting accepted is always an awesome feeling! Our talk is called “Making the Difficult Simple(r)”, and it’s dedicated to the concept of how APIs are like products.

Making the Difficult, Simple(r) from Ken Tabor

Sabre has a rich heritage in APIs, and we were excited to share some of our hard-earned knowledge from the past few years. We’ve discovered a lot, and we recognized this conference was an effective way to deliver takeaways to an engaged audience.

Tech-driven products, like APIs, seem like special items, and that makes them difficult. It’s difficult planning their strategy, it’s difficult scheduling their implementation, and it’s difficult selling them to customers. All of that can be true, but there’s help. In our talk, we propose making API product management simple. How? By taking lessons across the history of product design and development from traditional industries. That’s the heart of our talk.

Attending Gave Me Ideas

I heard a lot of excellent ideas across the two-day conference. Each of the collected speakers is an expert in their own aspect of API design, development, and delivery. Out of all the many things that I could tell you about, these are my top takeaways and the most compelling topics:

  • API-First Mindset
  • Security
  • Developer Experience

API-first Mindset

Is your industry programmable? Established companies create a genuine business value and gain concrete expertise after years of operation. Is there strategic opportunity in sharing that capability with others? Specifically, by making APIs empowering software developers to do in their applications the sorts of things that you’re good at in yours.

For example, the following industries could create simple-to-use APIs that makes their process easily done in apps: banking, analytics, machine learning, 3D graphics, and travel. If the industry you’re in isn’t programmable via APIs, should it be? It might sound impossible, undesired, or ridiculous, and that’s why it’s never been done before. It might lead to disrupting your competitors by creating more offerings for new partners.

Don’t think that you’re giving away your business for free. APIs have commercial models defining paths to monetization. At a high level, we can think of APIs as a utility. You can measure use, bill on consumption, and even turn off at the source.

Best practices:

  • Search the web to find many well-documented commercial models for one that meets your needs
  • Start making APIs for internal use to drive quick innovation across your company, and then expose those externally to acquire new partners
  • Train your existing product managers on API technology

Security

Computers are relatively easy to break in to. Not that it’s simple, but it’s much easier as compared to traditional physical locks. Why? Because of the interconnected world. Someone on the other side of the globe can attempt to break into a device sitting beside you if it’s connected to the Internet. Proximity mattered in the old-world. In the digital world, a malicious attacker has a much further reach.

Past-world smash-and-grab robberies had limited losses. A few pairs of thieving hands could escape carrying only a few bags of jewels and silverware while alarms sounded. In the new world, a hacker can escape with large volumes of private and personal data. Sometimes undetected for hours, days, or weeks.

Best practices:

  • Have an API authentication scheme in place. For example, OAuth
  • Include your security team at the start of a project to design a strong API rather than asking for their approval once development is done
  • Implement a method of detecting break-in. For example, use open source monitoring of your server access logs

Developer Experience

Teams building APIs must ask themselves this question, “What type of experience do I want my customers to have while using my digital tools?” Customers of APIs are developers, so the developer experience (DX) is critical. Positive experience mean your APIs are more quickly integrated into the customer’s app, and revenue starts flowing faster.

Negative experiences spawn from confusing API responses, non-standard status codes, frustrating debugging sessions, more support tickets, missed deadlines, and bad feelings. Ultimately, it leads to developers wondering what the alternatives are, and in technology, there’s always another way to solve a problem.

Developers using your APIs are a savvy bunch. Think of it this way. Your APIs are one set used inside of an application. That means your work is sitting alongside other APIs, and you can bet that some of them are made by world-class companies. How do your APIs measure up in comparison? At this point, it’s not good enough to simply be better than your closest competitors. Developers have come to expect high-quality, and they’ll find it.

How can we provide good DX? Talk to your customers, find out what problems they’re having, and ask, “How might we help you do X?” Figure out all of the possible solutions that you could come up with. Make some prototypes and test them with your customers. Learn what’s possible, useful, and good business. That sounds pretty simple, right?

Best practices:

  • Write documentation for getting started, in-depth how-to guides, API references, change logs, and be sure to revise them as needed
  • Create API design that’s intended to be human-readable
  • Offer SDKs that are fine-tuned for the idiomatic best-practices of each programming language you choose to support

Summary

I could have doubled this trip report. Ultimately, I wanted to write a brief review of the most outstanding ideas that I took away from the Nordic API Summit. Reach out to me on Twitter anytime to talk about these topics or just want to share what you think about APIs.

    About Ken Tabor

    Ken Tabor is a veteran programmer with years of experience developing websites, mobile apps, and video games. He shares his enthusiasm for technology as a writer, teacher, and frequent speaker at conferences including South by Southwest, DevNexus, and Big Design. Ken is currently a software architect at Sabre helping foster a modern developer experience for its future API platform. Areas of interest include NodeJS, Kubernetes, UX, machine learning, and design thinking. He is the author of, Responsive Web Design Toolkit, published by Focal Press. When Ken isn’t working he’s having an adventure with his daughter. They’re always looking for the best chocolate, books, and coffee in Dallas.