From October 22-23, Nordic APIs hosted our 5th annual Platform Summit in Stockholm, Sweden. #PS19 brought together over 450 total attendees and hosted 65 speakers across three stages. In the coming months, we’ll review many of the great talks shared with in-depth analysis on the blog. But for now, let’s check out some of the main highlights.

SLIDES	SESSIONS	SLACK	PHOTOS	#PS19
View speaker slides	Watch the recorded talks on our YouTube Channel	Invite link to continue the discussion	View photos from the event	Read event chatter on Twitter

Highlight Reel: PS19 Edition

Our yearly Platform Summit continues to grow, gathering broad perspectives on API business models and expert technical advice. We’re always impressed with how our speakers approach so many insightful topics along the API lifecycle! Our community is similarly avid to discuss, with poignant Q&A throughout the event. Below are some favorite ideas and quotes from the sessions I was able to attend.

API Platforms

Today’s platforms are starting to look like a combination of many APIs. For example, the increase in SaaS services for areas like DevOps tooling means a staggering increase in API connections. This new paradigm is essentially about automation. Companies are utilizing trigger and event-based tools to automate much of the development workflow.

Though automation is necessary to achieve continuous delivery, keynote speaker Tina Huang of Transposit sees a danger in fully relying on automation. Instead, she advocates for a healthy union of the two; something she calls human-in-the-loop automation.

“Human in the loop automation is automation where each step along the way we give humans the ability to interact and influence its direction,” said Tina. “Rather than thinking man vs machine, it’s about thinking where humans can add the most value, then automating out the tedious parts.”

Tina calls this API composition, stressing the need for a layer to help compose API connections.

To showcase sample API platforms, we took a look at the supply chain industry with Dave Holliday from Maersk. Dave described the technical logistics of one of the world’s largest shipping container companies.

Whenever a Maersk container is processed, a file is generated and distributed around the world. Some of the largest vessels have 18,000 containers at a time, equating to millions of individual data points. All this uses a 50-year-old technology, EDI (Electronic Data Interchange).

“EDI is a hideous message, very hard to consume, and very difficult to develop against,” said Dave. “EDI is a standard, and everyone implements the standard differently.”

Therefore, Maersk built an API to enable automation around the platform. According to Dave, “we must be embracing industry standards within API design to make it interoperable and easy to consume.”

API Strategy

Moving to an open API mindest is still difficult for some enterprises. Maria Garcia from Amadeus described how some business executives find too many risks with API adoption.

“Will it canibalize exisitng renuve streams? We’ve always done it this way. It’s not in the budget. We’re doing ok so far. We have other priorities…”

Resistance to change is natural, but stagnation could be detrimental. Maria reminds the reluctant API luddites that “disruption can happen any time anywhere.” When pushing for new API initiatives, she advocates small iterations with a balanced Bimodal IT approach. To demonstrate the potential of APIs, start with an MVP using a low-risk connection, such as GET HTTP calls.

Usually, technical debt isn’t something to be proud of. Will purchasing more tools help avoid digital paralysis? In our world of service messes and few holistic IT experts, Ahmet Soormally posed a rather bleak view of current platform architecture:

“Everything was better when everything was worse.”

To maintain a failsafe when tech adoption gets messy, Ahmet recommends building on open standards to avoid vendor lock-in.

Within the same track, Geir Sjurseth, Apigee Tech Strategist at Google, had quite a different perspective. Geir proposed that for today’s API-driven microservices, the time and resources needed to support and maintain open standard initiatives ultimately outweighs the risk of lock-in. In his words, lock-in is ok if you’re locked into “heaven.”

When considering development processes, Pelin Dumas of ABN Amro Bank Open Banking described how they use a DARE methodology, a development process that combines design, lean, and agile thinking. At Amro, API projects traverse stages within the development continuum: ideation, prototype, pilot, closed beta, and live. At each stage, there is a validation check.

“We are expecting in 3-5 years for APIs to become business as usual within our market,” said Pelin.

API Design

curl: the open-source command-line tool that dominated the world.

Did you know that curl has over 220 features? Or that it can run on 71 operating systems? Or, that even though curl is 22 years old and is on version 186, every curl iteration is backward compatible?

We were honored to host the founder of curl himself, Daniel Stenberg, at The Platform Summit. Daniel explained how curl conquered the world, demonstrating countless features to show just how robust the tool has become. One thing was clear; he sure hates it when developers overuse -X incorrectly.

Another favorite talk was Zdenek “Z” Nemec‘s follow up to last year’s presentation, in which he weighed the benefits of REST vs. GraphQL. In this year’s comprehensive session, he compared 8 API styles that all API developers should be aware of.

If you are a software architect, this is the minimum number of #API styles you should consider when thinking about your next API project:

1. REST APIs
2. So-called REST APIs
3. GraphQL
4. Apache Kafka
5. WebSub
6. SOAP
7. gRPC
8. File transfer

via @zdne at #nordicapis #ps19

— 𝙱𝚒𝚕𝚕 𝙳𝚘𝚎𝚛𝚛𝚏𝚎𝚕𝚍 (@DoerrfeldBill) October 23, 2019

When designing an API, Z recommends architects consider how their constraints will dictate API style. In turn, the properties of an API architectural style will affect performance, scalability, simplicity, modifiability, visibility, and portability.

APIs designed without rich links and information likely won’t satisfy all these properties. That’s where hypermedia comes in.

“REST’s uniform interface constraint is not only about the protocol HTTP – one must also consider the media type and possible app specific semantics, ” said Tomasz Pluskiewicz.

For implementing HATEAOS, Tomasz recommends the Hydra client. He demonstrated the benefits of this robust framework in an in-depth code walkthrough.

API Security

Jacob Ideskog from Curity introduced The API Security Maturity Model, which repurposes the Richardson Maturity Model in a security context. The model is constructed as follows, with high maturity at the top, and low maturity at the bottom:

• Centralized trust using claims
• Token-based authorization
• Token-based authentication
• API keys and basic authentication

Jacob stressed that building identity directly into URIs, and thus API calls, is a dangerous practice. He cited one case study, a Swish vulnerability, in which a developer was able to decompile the app to expose user payment information.

Francois Lascelles from Ping Identity believes API traffic metadata is precious and underutilized. It provides better API visibility with rich insights and brings security benefits.

“Your API is either well documented or easily reverse-engineered” – Francois Lascelles

According to Francois, by inspecting runtime traffic, API providers can better tell when a black hat uses a token or IP address outside a legitimate application. Analyzing API traffic requires a machine learning system whose accuracy increases with each request it monitors.

API Marketing

Something we don’t think about often is scalability for developer portals. Many developer centers now utilize a layered content architecture with individual Open API Specification, Markdown, and JSON files for each API. Without substantial business focus for these services, developer experience will easily fracture into “ghosts of SOA past,” says veteran Nordic APIs speaker Kristof Van Tomme.

“We’ve got everything bet on [APIs]. We need our customers to become really successful,” said Kristof, identifying the need to transmute value to end developer consumers. Kristof believes the right method for achieving this is by becoming an affordance platform, and developer portals must reflect that. Affordance platforms are less rigid than complicated enterprise systems. Instead, they embrace a biologically-inspired organization as “complex adaptive systems.” Must read: Conway’s Law.

API Business

To realize an API as a product, Kevin Bouwmeester from Google Apigee recommends using outside-in thinking. Next, API products require speed to market and iterative delivery.

“Like how Legos are packaged, APIs are made visible and sold at the devleoper portal,” said Kevin.

According to Kevin, a holistic developer portal includes a catalog with SDKs, monetization, documentation, a marketplace, and other features.

However, APIs are more than products; they may bring more indirect benefits than direct monetization. APIs also have the power to automate many aspects of the business. Alan Glickenhouse sees more gains in indirect API business models. In his presentation, he noted that if you think API revenue is all about direct monetization, you’re missing out on many other aspects.

Speaking of indirect business models, how do you make money with open-source? In his talk, Philipp Krenn from Elastic explained how open-source is a viable strategy, but the money must come in through support, consulting, training, and/or certification.

“Everyone wants to be paid for their work, but on the other hand, we all want well maintained open source software,” said Philipp.

And the Winner Is…

Throughout the last few months, our community submitted votes for the Best Public API of 2019 competition. At the Platform Summit, we announced our winner: Shutterstock. Congratulations to them!

We believe assessing the traits of what makes a quality API helps the overall community. Models and case studies such as these are essential for propelling the space forward. We plan on arranging a 2020 competition, so stay tuned!

Nordic APIs mission: Make the world programmable

Thank you!

Thank you to our fantastic speaker lineup, attendees, sponsors, venue, and event crew for making this possible! It’s an honor to host an event that brings together such a solid community. We really respect the work everyone is doing to advance API greatness.

Thank you to our sponsors: Apigee, Redpill Linpro, WSO2, Ping Identity, Entiros, NGINX, Tyk, Axway, and APIIDA. Are you interested in sponsoring Nordic APIs? Please contact us here.

Also special thanks to media partners Swedish FinTech Association and API:World for helping us spread the word about the conference.

Feedback

Do you have constructive feedback on this year’s Platform Summit? We’d love to hear. If you attended the event, please fill out the survey we emailed you.