It was a great conference to attend and see so many new talks on the exciting advancements in the OpenAPI space and also how the world is changing the post-API economy.
The theme of the event was APIs for Smarter Platforms and Business Processes, there were many talks which focused on the future of how APIs are evolving and how they could work in the not-so-distant future.
Here are my top talks from the conference, some of which have a recording on the APIDays YouTube channel:
API Management is Broken
Josh Twist from Zuplo, watch the talk on YouTube
Josh has certainly been around the block after creating Azure API Management at Microsoft and being the Head of API Product at both Stripe and Facebook, all notorious companies in the API space. He went through his good and bad experiences with his previous employers. He covered why he started his own company in order to address the issues he faced and make the lives of engineers easier by fixing API Management.
I certainly felt a connection with the bad API management practices that Josh described, it’s an issue across all sizes of companies. Being able to implement a feature like API keys or rate limiting gets really painful when you have distributed services and different entry points into the API.
The solution is having one place you can configure these features of an API gateway across all endpoints. When companies are scaling up their APIs, the API management level often becomes a real bottleneck, quite frequently with some sort of council of governance that ensures consistency across all APIs.
Everything Everywhere All at Once: API as a Product
Rob Prince from Just Eat TakeAway, watch the talk on YouTube
The aim of your API is to do everything, be everywhere, all at once; having a pure system which can always be available and fulfil every customer need.
In order to have everything everywhere all at once, you have to break down the “right” and “right-size” microservices. Microservices, by definition, are intended to be “organized around business capabilities”. Having microservices too big means there’s no benefit using a monolith architecture, being too large to make quick and targeted changes. Having microservices too small will mean many services being owned by a single team, which adds a lot of complexity to interactions. When microservices are the “right-size”, services serve one capability and have a rich, related and useful set of features.
Mapping your business capabilities to the teams that provide a service which supplies it will show where there are duplications. Using the APQC framework, you can look at a top-level business area and a business use case, and define all the business processes which fit into the business process. These processes are likely candidates for microservices, ensuring that you will have split the services into capabilities.
You can then group all the APIs that your business capabilities use in order to identify the “API Products”. By having a clear and defined API Product, the use cases are infinite as to what can be done, which means when the business comes up with a new use case the tech will already be in place for it to be fulfilled.
Designing and Evolving API Based Systems
James Gough from Morgan Stanley
The focus of his talk was ensuring that your API aligns to the core principals which make it easier for consumers to integrate. Beyond having some sort of specification (OpenAPI, Swagger, Protocol Buffers IDL, AsyncAPI, etc.) there should also be further standards to how your API is structured.
By conforming to a well-established API standard, your API will be consistent across security, versioning and endpoint structure. This enables faster integration and more few issues when downstream consumers use the API as they have a better understanding of how to use it.
Loose coupling is also a cornerstone for developing a good API, having weak association between components in the architecture means that you can redeploy services, change cloud providers and refactor anything in the ecosystem without it being too much of a nightmare. Versioning different components empowers the loose coupling throughout the system.
API Governance Without Tears
Lorna Mitchell from Redocly
Lorna really emphasised how important API governance is, not only does it enforce consistency across APIs and make changes faster to complete, but it also acts as an invisible force that ensures users have a better experience with your API. The difficultly is getting everyone within the organisation to be onboard with following the standards from day one.
The starting point is to follow already established practices and technologies, reinventing the wheel will only cause more friction. Having an OpenAPI specification means that all APIs can be aligned consistently in style and standards, as well as supporting the tooling to enable fast feedback and easier documentation.
Rulesets should be incremented in levels, starting with a valid OpenAPI document, then meet the basic compliance standards, then consistency across the whole API, then making the API a joy to work with. This builds up rules for enforcing security on endpoints, ensuring consistency with plural names and casings, then onto building real examples and having meaningful descriptions.
Finding the right level of all the rulsets is difficult, but that level will be the identity of the API, having regular reviews over time will guide where the level will be and ensure that the API is always evolving. There are an incredible amount of tools for working with an OpenAPI spec which will drive a lot of business and engineering value.
The API Workflows Specification — The Missing Piece Of The API Puzzle?
Frank Kilcommins from SmartBear
The OpenAPI Initiative (OAI) have a Workflows group which are building a way to be able to express specific sequences of calls and articulate the dependencies between them to achieve a particular goal in the context of an API specification. This means that where OpenAPI spec defines what your endpoints are, a Workflow spec defines how to call the series a endpoints to achieve an objective.
Having automatically generated documentation from an OpenAPI spec is a good start for onboarding partners onto your API, but you also have to write guides and runbooks in order to demonstrate how to use it. This is where Workflows fill the gap, you can define your guides in a workflow spec.
The workflow contains a series of inputs, steps and outputs. The inputs are for the setup of running the whole workflow. The steps document a series of operationIds (endpoints in the API) which can then have inputs and outputs, these are then chained to form the workflow, resulting in the outputs of the workflow from the result of the final step.
While bridging the gap of having a consistent way of writing API guides, the workflow can also be used as a means of testing the API through use cases. They can also break up large APIs into smaller chunks where a consumer may only want a few endpoints to complete a use case.
Personally, I would highly recommend the APIDays conferences, which are hosted all around the world. After feeling inspired while attending the London conference, I applied to join the speaker list for the Paris conference in December 2023, which to my surprise was accepted and I’m very much excited for. Please come join me there and say hello! 👋