Ken’s Nordic 2018 Platform Summit Trip Report

by Ken Tabor

Colorful houses on Stortorget Square in Stockholm

The Nordic 2018 Platform Summit is a curated international event featuring top API speakers from across the world. The conference took place in Stockholm, Sweden on October 22-25. Approximately 500 people attended the Nordic Platform Summit across a three-day schedule. There were 60 speakers and each of the talks was twenty minutes long.

This trip report highlights standards and best practices for API business and technology from a selection of the talks.

I’ve listed five of the most memorable talks that I heard. Each has a link to its recorded video, and you’ll find several takeaways giving a sense of each topic. Have a look as time permits. As a bonus, you’ll see notes on the talk I gave reviewing some of the best practices we’ve learned building APIs across Sabre.

The Design of Everyday APIs

by Arnaud Lauret of Natixis

  • An API is first and foremost an interface for developers, for people. An API must have a purpose that makes sense for these people. An API must fulfill these people’s needs without bothering them with internal concerns.
  • There are three things to think about to achieve a straight-forward design that people will understand instantly: representations, interactions, and flows.
  • Understandable API design is predictable and consistent. Consistency comes from the API itself, across your organization, and common practices & standards.

Framework for Successful API Governance

by Jayadeba Jena of Paypal

  • First APIs launched in 2004, were SOAP. Rethink their platform in 2013 and rebuilt all APIs using REST.
  • Their API program has metrics to measure an API to categorize an API as good or bad.
  • They documented styles and patterns:
    • Service design principles
    • API standards
    • Common object definitions
    • Versioning
  • Governance started as a centralized team which became a bottleneck. Changed to a federated team. All written criteria (standards and principles) in their API Maturity Model is used by [Org Leaders, Domain Architects, Product Managers] to evaluate an API spec to decide if it’s ready to go to development for live integration.
  • API culture takes a long time. Takes an investment. Is never-ending.

Evolution of API Management in the BBC

by Nathan Brock and Rafal Jachimczyk of BBC

  • They found a centralized API management layer became a single point of failure. When a new team was onboarding, they misconfigured a proxy and it went wrong for everybody because it’s a shared resource.
  • Decentralized. API configuration was treated like code. Server-side proxy data is stored in revision control. Passed through a CI/CD process.
  • Their Developer Portal is built for an internal audience.

Pain Points in API Development? They’re Everywhere

Abhinav Asthana (Founder & CEO, Postman)

  • If an API has observable behaviors, consumers will use it. Even if it’s not documented. SEE: Hyrum’s Law
  • Common problems while consuming APIs:
    • Little or no documentation
    • Too much academic reference and not enough practical samples
    • Lack of business use-cases (API product lacked input from sales and marketing)
  • There are three core development loops through which an API progresses: technical abstraction, product abstraction, company abstraction
  • Build a Slack-bot with your API. See whether your API is useful or not.

Best Practices for API Design to Keep Your App Secure, Scalable and Efficient

by Amjad Afanah of FX Labs

  • 500 status code. Be very careful not to just dump your entire stack trace when an internal error happens. Otherwise, you’re giving hackers an opportunity to reverse engineer how your application is working.
  • Think about API design implications for security. Pagination for example. You must have limits otherwise opening the door to a DDOS attack.
  • RBAC (role-based access control). User management gets tricky if they can gain multiple roles with more permissions. They partner with [auth0, Okta, Curity]. Suggests automated testing to detect major security vulnerabilities continuously because admins will change role permissions in the system over time.
  • “Shift Left” testing. Get bugs found in the earliest part of the development cycle when it’s easiest and cheapest time to make a change.

Making the Difficult, Simple(r)

By Ken Tabor of Sabre

  • APIs are made for humans to use. Ideally, you’ll conduct your API Design from the point of view of the customer – software developers.
  • Speaking to APIs is like speaking to any other product:
    • Research customers and markets to discover their problems
    • Understand your company’s core capabilities
    • Deliver solutions, watch how people use your work and continuously evolve to meet their needs
  • Why consider developer experience (DX) now? Developers are increasingly the decision makers and certainly influencers.

All Speaker Sessions

Do you have time to watch all of the talk videos? They’re collected together in the 2018 Platform Summit playlist.


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 BigDesign, South by Southwest, and DevNexus. He is the author of, Responsive Web Design Toolkit, published by Focal Press. Areas of interest include JavaScript, augmented reality, developer experience, machine learning, and design thinking. Ken is currently a software architect at Sabre helping foster a modern developer experience for its future API platform. Feel free to reach out to Ken on Twitter @KenTabor