Mic check. 1-2-3. Earlier this week, Nordic APIs held a 2.5 day event, jam-packed with workshops, 30 speakers, and critical insights on building success in the API ecosystem. This was our first ever conference in Austin, and our 2nd ever Nordic APIs event in the United States.
We had a blast, learned a lot, and want to share with you some of the best knowledge gained this week. We saw a lot of tried-and true-topics around API productization emerge. We also gained insights on developer portal swiftness, SDK auto generation, advanced access management, scaling OpenAPI, CI tooling/DevOps, serverless, AI modeling, and more.
Below I’ve outlined some general takeaways, and highlighted some speaker sessions that took API practice to the next level. Head to the bottom for specific resources mentioned by speakers.
We hope to return to Austin, but in the mean time please keep updated with Nordic APIs, and consider participating in our Platform Summit 2018, occurring from Oct 22-24 in Stockholm.
Overall Trends + Quick Takeaways
- Companies have embraced API Productization: “API-as-a-Product” took the cake at this conference. (Someone said speakers mentioned it around 14 times). Are you surprised that in 2018 we are still talking about APIs as a Product? A little. Maybe some still haven’t quite gotten the point yet.
- The API Product Manager role is now accepted and in high demand: It’s not just us reiterating the product point! A recent report published by Gartner says that “Creating the role of API product manager is key to managing [the] project/product dichotomy.” This seems to be part of a trend, as more and more API Product Managers rise to lead API initiatives.
- The debate between SDK auto-generation and handmade is on: We heard both sides on this one. The arguments are that reuse leads to sacrificed usability and less idiomatic SDKs, but code generation with tools like Swagger CodeGen or APImatic saves time and resources and improves CI automation. The debate is on!
- Security is a top concern in API practice: Speakers from Okta, Nevatech, and Curity all shared insights on various methods for securing and managing APIs. It’s evident that a complex API security mechanism is a necessary response to the current hysteria surrounding data privacy and public breaches.
- Developer relations and business cases direct development: APIs are now products (did you catch that?), meaning the developer is always right. When designing developer experiences, be as intuitive as possible. It’s not about you, it’s about consumer preferences, which must come first.
- Automation is now a top concern for any agile IT business: From SDK auto-generation, automating consistency in API design, using Jenkins to update automate client-facing assets, serverless, and more, we saw how tooling strategies are seeking ways to automate platform operations.
- RTFM works sometimes, so why not set it up?: Create an auto reply for support questions (Read The “Friendly” Manual). Sometimes it does work and reduce time!
- We’re over “vs.” and now use “and” when comparing API styles: Stubborn competition between standards can lead to a lot of unnecessary squabble. Many now acknowledge separate and valid use cases for things like REST, GraphQL, gRPC, and other design styles.
API Product Managers are becoming more common. I’ve met a couple already this morning. This is a good sign. #nordicapis
— Adam DuVander (@adamd) June 12, 2018
Speaker Session Spotlights:
Lenny Markus, Paypal
Consider Progressive Disclosure to improve developer experience
In his session RTFM (Read the Friendly Manual), Lenny Markus of Paypal outlined some ideas for improving API references to cater to developers in a usable way.
What animal represents a developer? Lenny depicts a cunning, yet sleepy tiger. Developers are smart, but lazy in that they will take the path of least resistance to get something done.
In that vein, Lenny highlights a philosophy called Progressive Disclosure, which is essentially an interaction design technique that reduces clutter to make it easy as possible for the user. Paypal is currently reinventing their developer portal to have more progressive attributes, and we were given a sneak peek. Since they now have hundreds of developer-centric products, their new portal will have a product explorer to help narrow down the service discovery process; a simple change, but an effective one to greatly improve developer experience.
Cecy Correa, Context.IO
Support the support engineers! Fight trolls and promote healthy working hours
Developers can get irate! When a function doesn’t work some get angry, and use foul language in nasty passive aggressive emails (we saw some unfortunate screenshots).
A great lesson for API project managers and support team leads is to remember to protect you team. As Cecy mentions: “Your team’s sanity and happiness comes first.” This means avoiding abuse at all costs. Cecy’s firm anti-harassment policy involves politely letting consumers know Context.io has no problem cutting off API access if they don’t change their ‘tude.
She also recommends teams stick to business hours! Support tickets arrive in all hours of day. If you work outside of business hours just once, that could set a dangerous precedent the client will now expect of you. Prioritize a healthy support engineering culture to protect your team; otherwise they will burn out.
Michael Hibay, Slalom
UX benefits from hypermedia make it worth the effort
If an API is a product, then how you design your API is business critical. In his talk User Experience: Building With Hypermedia for Other Folks, Michael Hibay of Slalom made a case for including hypermedia as a user experience multiplier. Why is hypermedia a good idea? Michael believes it results in a simple API.
“A simple API is one which is designed and interacted with in the same manner as the domain it mirrors”
A simple API should bring no cognitive dissonance to an actor in that domain. Though Michael acknowledges some potential risks (human error, A priori knowledge, redundant logic), in his view the UX benefits from hypermedia outweigh additional upfront design effort.
Travis Spencer, Curity
Maybe OAuth should really be named ODelegate…
Following a half day workshop on the subject, within a grouping of API security talks Travis Spencer of Curity sought to connect the dots between OAuth and OpenID Connect.
He considers OAuth as a “meta framework” of sorts; a protocols of protocols. Did you know 50 RFCs exist to define how all these standards work together? The complexity is compounded with the misnomer that the Auth in OAuth often implies authentication. Travis reiterates that OAuth is not about authentication, it’s actually about delegation.
Travis imparted a ton of useful OAuth information on the capabilities of using tokens. He defined the type of OAuth tokens such as access tokens (like a session, used to secure API calls), or refresh tokens (refresh tokens, like a password, used to get new access tokens). He touched on the differences between OAuth flows
(Basic, Implicit, Hybrid flow, fAPI), as well as OAuth code flows involving OpenID.
Eyal Sivan, CIBC
They say banks must behave like tech companies to survive… this one is taking the advice seriously
In his talk, Eyal Sivan explored some cutting-edge, progressive development and research conducted by… a large bank. Wait, is that right? Yes, Canadian bank CIBC is making some drastic shifts to survive in the true paradigm shift that is open banking.
Having cooked with enterprise software design spanning decades, Eyal is still trying to wash out the marinara stains from the “spaghetti” of enterprise ESB, EAI, and SOA architecture styles. However, he now thinks he’s found his bleach.
Eschewing ESBs and API gateways, Eyal considers service mesh a more evolutionary model. He feels that “service to service communication is best handled in a distributed way.” He also notes that:
“If your goal is speed, microservices is your secret sauce, not APIs”
A lot is changing due to regulatory pressure (PSD2) and new market expectations. Banks could soon be “Uberized.” Replace winter is coming with silicon valley is coming and you’ll understand the fear. Using a microservices framework based on open-source tech is CIBC’s method to stay relevant through turbulence.
James Higginbotham, LaunchAny
What API design style should I use?
Through his API consulting work via LaunchAny, James Higginbotham is all too familiar with this question. In his session Are REST APIs Still Relevant Today?, he examines popular API styles of 2018 — GraphQL, gRPC, REST, and webhooks — to try and find the answer.
Since APIs can be used to solve a variety of use cases, James recommends you consider what style of interaction your API will have before adopting one or the other: Is it request/response, like the majority of endpoints, or request/acknowledge, or do you really need to
GET batch data? He then compares styles as such:
- GraphQL: Works well with object graphs. Hierarchical data support. Good fit for front end APIs. Limited security enforcement. Lack of cacheability. Constrained to specific content types.
- GRPC: Resembles CORBA. high performance potential — see Google Cloud SDK as evidence. HTTP 2 / bidirectional. Low latency. Uses protobufs for code generation. Dependent on code generators to do the right thing. Lack of cahceability. Better for backend.
- REST: HTTP + JSON is dependable. URLS define resources paths, verbs allow server interaction. Headers take details, we have response codes, content negotiation, caching, and concurrency control. Hypermedia can offer customization for unique devices or interfaces. Read his deep dive into HTTP concepts here.
- Webhooks: Big potential. For example, Github uses webhooks for all pull requests, they’ve “created an entire marketplace that didn’t exist before” that would’nt exist without webhooks.
Ultimately, Yes, REST is still very relevant. However, figure out what styles will accommodate the majority of developers and channels you are creating and build accordingly.
Kelly Grizzle, Sailpoint
He’s dominating the world with an API for provisioning user data
We often discuss the differences between public-facing APIs, partner APIs, and APIs used strictly for private, internal purposes. We’d like to introduce a 4th breed: the Internet standard API. As we’ve covered on the blog in the past, SCIM, System for Cross-Domain Identity Management, is a new standard for identity management. The goal is to make it fast, cheap, and easy to move users into and around the cloud by automating user provisioning with a REST API. In his talk, Kelly Grizzle of Sailpoint announces his goal for “world domination” — with 2.0 released in 2015 as ETF RFC 7643, SCIM is now adopted by hundreds of organizations worldwide, and adoption grows.
Words of API Wisdom
- “APIs are not about integration, they’re about frictionless consumption” –Lou Powell, Vanick Digital
- Kristof Van Tomme of Provonix described how we really need more focus on internal APIs, and I agree. Perhaps they can take a page from the innersourcing community.
- “When you optimize for reuse you usually sacrifice usability” – Irakli Nadareishvili
- Anyone remember playing the retro Lemonade Stand computer game? Chris Busse of APIVista believes that API providers too could use a similar dose of basic economics.
- “Always follow a top down approach— start from business need and consumer need, then use that to design APIs” – Keshav Vasudevan, SmartBear
Resources From Speaker Sessions
For further exploration, here are links to frameworks, studies, and other resources emphasized by speakers:
- Cloud Elements’ State of the Union: Check out Cloud Elements’ yearly survey, as reviewed by Ross Garrett in his presentation.
- Pact Framework: This framework for contract driven design was reviewed by Henrik Stene of Knowit. He flew all the way from Norway. Congrats on your first conference talk, Henrik!
- Power of HTTP: James Higginbotham mentioned his comprehensive overview of HTTP concepts. Read to ensure you’re getting the most out of HTTP.
- OpenAPI Generator: Tristan Sokol of Square identified how they auto-generate SDKs using Swagger Code Gen and and TravisCI.
- Kaltura API Client Library Generator: Avital Tzubeli from Kaltura described this in-house client generator they made to create idiomatic SDKs. Github Repo.
- OpenAPI Specification: Learn about the spec, available tooling, and the community surrounding it.
Have More Insights?
Did you enjoy any specific sessions or have any questions for speakers? We’d love to read your feedback in a comment below. On that note, if you’d like to give a session in the future, here is our Call For Papers.
Survey: Help Us Improve
We kindly ask all attendees: please fill out our 10 question survey. It will greatly aid our efforts to improve our events and return to Austin!
Thank you to our organizer Curity, and to our sponsors SmartBear, Stoplight, and Nevatech! We wouldn’t be able to curate such events without your support! Are you interested in sponsoring an upcoming event? Head to this page for details.
Next Up: Platform Summit 2018
We plan on returning to the U.S. in the future, but between then and now is the 2018 Platform Summit in Stockholm, Sweden in Oct 22nd – 24th. This will be our largest event yet, a truly global API conference including top notch speakers representing all the major players in the industry. Attendees: grab you ticket today and stay tuned for announcements by signing up to our newsletter!