- Content Services for Lodging Deep Dive Part 3: Checking Prices
- Content Services for Lodging Deep Dive Part 2: Getting Details
- Content Services for Lodging Deep Dive Part 1: Getting Availability
- Looking at Lodging APIs Part 2: What You Can Do with Them and Looking Forward
- Looking at Lodging APIs Part 1: Why We Built Them and How You Might See Them
- 6 Powerful Ways Content Services for Lodging Will Change How You Access Hotels Today
- APIs Need Protocols
- 10 Technologies that a Programmer Should Learn in 2019
- Ken’s Nordic 2018 Platform Summit Trip Report
- July 2019
- June 2019
- May 2019
- March 2019
- December 2018
- November 2018
- October 2018
- September 2018
- August 2018
- July 2018
- June 2018
- May 2018
- March 2018
- January 2018
- November 2017
- October 2017
- August 2017
- July 2017
- June 2017
- May 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
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
- 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.