API Specifications Conference 2021

In today’s complicated application landscape, the APIs are the foundation of any integration as well as digital transformation, and the API specifications are quickly becoming a very important component of the company public image. Many large companies (including ADP) expose a broad variety of capabilities targeted to different consumers and the API specifications should be flexible enough to reflect different usage contexts, i.e., geo-political, industry specific, level/tier of service, etc.

This session focuses on creating and exposing contextualized API specifications that may include different operations, parameter obligation, customized descriptions / examples and potentially, different subsets of the same schema, depending on access entitlements of the consumers accessing the API Portal. The “design” view could also be combined with the runtime discovery of additional API “metadata”, thus allowing API providers for a greater flexibility exposing their API specifications to different consumers.

I am a big believer in the philosophy of working backwards from the customer. Although there has been a lot of focus and impetus on working with Specifications first and Code last; my aim in this talk is to take this one step further. I believe that one should start with the developer and their integration experience first and then work backwards from there to define the specification and finally resulting in code. There are significant advantages to this approach and I plan to use the talk to share about how do I do so in practice and how teams can build the muscle although it initially feels not natural to do so.

API consumers expect Service Level Agreements (SLAs) for production APIs which specify their capabilities such as rate limits, performance, quality and so on. However, currently the OpenAPI Spec (OAS) does not provide a method to capture SLA requirements within the specification.

The SLA for OpenAPI Special Interest Group has been working on a Spec for SLA definitions, that works hand in hand with OAS. In this talk, we will present the current state of the Spec, as well as the main use cases and benefits it enables: ranging from SLA documentation, automatic SLA enforcement, automatic middleware configuration, to SLA verification.

We will demonstrate how to generate OpenAPI with SLAs from their corresponding Service Level Objectives (SLOs) and how to make use of it in conjunction with your CI/CD pipeline and finally demonstrate measurement to performance and quality SLAs & SLOs with tooling against production APIs.

Finally, we'll then discuss how you can help improve and extend the spec by contributing to discussions and tooling.

In this talk we will cover a wide range of topics such as intro to graphql, why graphQl, concept of grapql (schema, queries, resolvers), making your first graphql query, resolving graphql queries with github mock API and the communities backing graphql

At the start of the year, as the result of a merger and acquisition, Stuart needed to integrate two different systems. There wasn't much in common between them: the systems were built by different teams in different tech stacks and with different engineering philosophies.

With an immovable deadline looming tied to a major marketing campaign, Stuart knew that the only way to ensure everything went smoothly was to discover integration errors as early as possible, and in a way that would force both teams to address them in time.

His tool of choice to pull this off? JSON Schema.

In this talk, Stuart will introduce you to what JSON Schema is, where it fits in the current developer landscape, and why it - and not OpenAPI Spec (yet! we're almost there) - was the right choice to ensure that a multi-million pound systems integration project went off without a hitch.

Finally, he'll show you how one of the teams is taking the JSON Schema foundation that came out of that project, and using it to accelerate the development of their single-page app.

"The OpenAPI Specification provides a way to document individual API calls and how to use them, but it doesn't give insight into the common ways to sequence those operations. While all APIs can benefit from formally describing these workflows, this is particularly important when considering more complex or more secure APIs.

The OpenAPI Workflows Special Interest Group was created to address this common problem. The goal is to construct a formal way to describe these sequences and support documentation of flows, such as a multi-part OAuth flow with JSON signing and refresh token behavior.

This talk will review the progress of the workgroup and describe progress toward a standardized way for describing how a particular API call works within the context of the service provided. We will also present work so far and concepts being considered for describing flows of individual calls in the context of the Specification.

A discussion AsyncAPI Specification 2.0 and its adoption in eBay’s developer ecosystem. Why eBay chose AsyncAPI Specification-based contracts to power its latest notification platform. How AsyncAPI Specification standardizes and simplifies the representation of a highly decoupled and resilient microservices topology.

This proposal for ASC 2021 would mainly revolve around some of the best practices while adopting Open API for asynchronous and synchronous scenarios. The talk, drawing from my experience, will also highlight some of the similarities and differences between OpenAPI and AsyncAPI, and on some of the standards that we should keep in our minds while documenting either of these. Above all, how does it help in improving Developer Experience & Governance.

Event-driven architectures are not new - but the way they are used, documented, and specified has matured significantly in the past few years. Events often trigger the broader patterns of behavior that your service was built to deliver, or complete chains of behavior with asynchronous components, but event-driven services do not exist in a vacuum - or in mono-culture.

In today's talk, we will discuss the use of specifications to link event-driven elements to the behavior of the broader system and where focusing on maturing your approach to event-driven architecture has the greatest payoff for your organization and your team.

For new members of our community or current members who want to get more involved - today's panel will take you through what the OpenAPI Initiative is, our mission - and how it has evolved, our working groups and committees, and how to start getting more engaged with the community of practice around the OpenAPI Specification.

With OpenAPI 3.1 fully adopting JSON Schema draft 2020-12, and AsyncAPI growth and use of JSON Schema, it's never been more important to really understand JSON Schema.

Draft 2019-09 and 2020-12 have introduced the notion of Dialects and Vocabularies, which opens up a standardised approach to extensions.

In this session you'll learn some key fundamentals, intracacies that even catch out the experienced, and how to develop your own interoperable JSON Schema Vocabulary.

If you're responsible for your organisations use of OpenAPI, AsyncAPI, JSON Schema, or any other technology that uses JSON Schema, this is your essential session for the year, brought to you by the JSON Schema project lead and publisher of the latest draft.

OpenAPI specs are fantastic complete descriptions of REST endpoints. Naively introspecting them to create the corresponding GraphQL API leads to technically correct, but verbose endpoints, often with 100s of types and queries, and complicated nesting structures. We believe that just like the Chunnel seamlessly merged two different driving sides (British and French), the OpenAPIGraphQL API must also balance the autogeneration from the OpenAPI spec with the consumption perspective of GraphQL.

We will show, using some real-world examples, how both introspection, as well as curation, can lead to a much better GraphQL API. Furthermore, since your GraphQL endpoint is almost never built on only one API backend, we will show why such curation is absolutely needed in the GraphQL layer.

This session will be of interest for all the developers who love the power and flexibility of GraphQL, but realize that a lot of the data is locked away in REST endpoints, and connecting the two is fundamental to any digital experience they are building.