- User Feedback Guides the Developer Experience
- One search does not fit all – diversify and create traveler persona rules for Bargain Finder Max
- 3 Big API Trends: My Nordic API Summit Trip Report
- Making the Difficult, Simple(r) Workshop at the Austin API Summit June 11-13, 2018
- Basic Fare Shop JR API (OTA_AirLowFareSearchLLSRQ) to be decommissioned
- 4 Ways the New Sabre Red Workspace SDK 3.3 Will Boost Your Agency’s Efficiency
- The Next Evolution of the Travel Desktop – Making Your Customers Happy Has Never Been Easier
- New options to revalidate an itinerary
- PCI-Mandated Upgrade to TLS v1.2
- Reducing Infrastructure Cost & Complexity with Sessionless Search
- July 2018
- June 2018
- May 2018
- March 2018
- January 2018
- November 2017
- October 2017
- August 2017
- July 2017
- June 2017
- May 2017
- April 2017
- March 2017
- January 2017
- December 2016
- November 2016
- September 2016
- July 2016
- June 2016
- May 2016
- April 2016
- March 2016
- February 2016
- December 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
Share this page
by Ken Tabor
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.
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
- Developer Experience
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.
- 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
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.
- 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
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?
- 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
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.