Recap of the Nordic API conferences
Published on October 20, 2023
It’s the 10 years of the Platform Summit, and we’re very excited to have been invited to speak and attend! Summit API, organized by Nordic APIs, is an event with more networking than a traditional conference. The topics covered this year are:
- API Platform
- API Business
- API Security
- API Design
- API Strategy
- API Marketing
Let's discover together the conferences that have left an impression on us.
APIs are more relevant than ever #
Bill Doerrfeld shared that APIs, and especially the API economy, are making headlines (TechCrunch, VentureBeat, Forbes) even if most people don't know what APIs are (e.g. Bill's grandma), and that's okay. We all use APIs in our daily lives.
- API calls represent 83% of web traffic.
- 89% of developers (even if not directly involved in the API space) use APIs.
- 98% of developers see APIs as a key tool in helping them and their teams get the work done.
Now, the most common industries are embracing APIs, including tech, business services, banking, industry, financial services, healthcare, education, automobile (Tesla APIs release), retail, entertainment, and more.
The Message Room Concept – How to Implement the Publish/Subscribe Pattern without a Centralised Message Broker #
Petteri Kivimäki gave an overview of X-Road, an open-source software designed for secure data exchange between organizations. It is primarily used by the public sector and relies on event-driven architecture and the publish/subscribe pattern. It operates on a decentralized architecture, implementing the message room concept and avoiding a centralized message broker.
API-First != Interface-First. A Platform Experience for Being An API-First Organization #
Nuwan Dias talked about the significance of API-First and the challenges developers encounter when building APIs in a Cloud native environment. API-first is a concept that is about prioritizing design and specification over focusing on the code level when building APIs. It represents a cultural approach to the entire API development process. While organizations may not explicitly aim to be API-first, their primary goal is to have functional solutions. API-first serves as a critical step in addressing the underlying issues, but the ultimate objective is to achieve effective results and get things done.
Evolving Your APIs, a Step-By-Step Approach #
Nicolas Fränkel introduced several API versioning strategies, which you can explore in his blog post at https://blog.frankel.ch/evolve-apis/. He also discussed the Sunset HTTP header, which is already implemented in API Platform, and the new Deprecation header, which is also an Internet Draft.
Demystifying API Governance: Building Success Through Understanding #
API governance, though essential, can encounter challenges in its implementation. It strives for consistency in API development but may inadvertently hamper developer productivity and even result in burnout. Arnaud Lauret suggests a more supportive approach, prioritizing practical guidelines, comprehensive training, and a thorough understanding of user requirements. Effective collaboration across all stakeholders and alignment with the overarching objective of maximizing the value derived from APIs are key principles. Arnaud ended his conference with this conclusion: API governance is helping people with a holistic approach to maximize API-generated value.
Navigating API Documentation: Tips From The Trenches #
Gertrude Chilufya Westrin gave tips about API documentation. It is a set of mostly written functions of an API and how to use it. The documentation should provide users with information they need to build integrations and make API calls with software. Her tips are:
- Read the docs (status, headers, links, filters…)
- What is the use case (who will use this)
- Check the sandbox/runable code (lowest possible barrier to get started)
- Have consistency across docs coverage and logic
- Don’t sleep on the changelog (quickly scan for any changes)
- Maintenance (update strategy, automate the process if possible, use AI if possible)
- Leave it better than you found it (create PRs if it’s an open repo, raise issues, give feedbacks)
The 10 REST commandments #
This talk from Steve McDougall is also available on this website. This is his commandments:
- Be practical (use a modern Content-Type, forget HTML, XML, Form Data etc)
- Be methodical (modelize your API as a set of resources)
- Be semantical (use standards)
- Be secure (use HTTPS, authorization, do your updates)
- Be consistent
- Be organized (use versioning)
- Be graceful (things fail, properly label HTTP response codes)
- Be smart (make sure that the API is optimized for cross platform solutions)
- Be Lean (caching is your best friend, HTTP/3)
- Be considerate (there are people depending on you to do a good job)
Unveiling the True Value of GraphQL: Beyond Overfetching and Underfetching #
Jens Neuse talked about the real value of GraphQL. It isn’t better nor worse than REST, it is different. Use the right tool for the right job: sometimes GraphQL is better and sometimes REST is. What is amazing in GraphQL:
- Community and ecosystem (confs, OSS, vendors etc)
- Observability (API producers get stats on how the API is used at the field level instead of at the path level)
- Monitoring (e.g. set the criticality of queries and mutations)
- Authentication and authorization
- Composite GraphQL schemas and federation
GraphQL Security Vulnerabilities in the Wild #
Escape scanned 1599 production public GraphQL APIs for security bulbs and 46K alerts have been found (the state of GraphQL security in 2023: https://escape.tech/resources/state-of-graphql-security-2023/). Tristan Kalos and Antoine Carossio showed their proprietary technology that enables the transmission of coherent real data, such as IDs, in requests rather than using fake data. However, despite advancements, traditional vulnerabilities persist in GraphQL, including misconfigurations, debug mode missteps, access control problems, and the lingering risk of SQL injections.
APIs with Bounded Contexts: Modeling APIs with Domain-Driven Design #
Jose Haro Peralta explained how the principles of domain-driven design help design APIs that are easier to understand and to consume. DDD can be a solution because it aligns software with business, incorporates the language of the business, it creates ubiquitous language, it's under the processes and flows of the business, it facilitates conversations between software and business.
You Don’t Need SDKs, Wait Maybe You Do? #
SDK stands for Software Developer Kits. It's more than just a package to install: it includes a code library, SDK reference, getting started guides, code samples, use case guides, and sample apps. Developers don't necessarily need an SDK, but many appreciate having one that abstracts the details.
There are some reasons not to create SDKs:
- When you are still proving the value of your API
- When you serve only a handful of developers
- When you have just a few endpoints and simple data structures
- When there are no strong competitors
According to Stripe, SDKs reduce the amount of work required to use their REST APIs. SDKs help reduce complexity.
Thank you Nordic APIs! #
In addition to all these inspiring conferences, we had the opportunity to present the talk Edge Side APIs: Fast and Reliable Hypermedia APIs. Congratulations again to the entire team that organized this event, which welcomed hundreds of people. A special mention goes to the community evening featuring The Ultimate ABBA Tribute Show. Without a doubt, we were in Scandinavia and hope to return next year!
