ASC 2022 - API Specifications Conference

Every day software development relies more and more on APIs. Using it as part of digital transformation or just to connect some microservices, developers use APIs to connect applications and devices. API management is now a mature discipline covering the different aspects of the API lifecycle. However, managing efficiently the surge of APIs in the organization could be a challenge. Using a declarative approach makes it easier to understand and automate the desired state of APIs. It makes it easier to version, review and share with other members of the team. Some projects have started to complement their capabilities to add this declarative approach, usually in environments like Kubernetes.

Join this session to learn more about:

Common API management artifacts
An introduction to declarative vs imperative management
The operator pattern and how it helps with declarative management
An example from the 3scale operator
Other projects using Kubernetes custom resources.

I would like to present you an innovative approach to design open APIs from business models.

This API Design First approach starts from the definition of the business use cases. Then the business models are designed, and finally, the open APIs specification are generated from the business models.

These models are designed at the entreprise level. A business concept is designed only once at the API level ... but also once at the whole enterprise level!

More than 95% of the time (workshops, modeling, design) is business oriented. Less than 5% is dedicated to technical design.
The approach is by the way, highly productive, consistent and error free.

To give you an order of magnitude, once business models are defined, a complex OAS (from 2000 to 3000 lines) is usually designed in less than 30 minutes with no error.

One of the main feature of the approach is that it allows to be focus on the business only.

This approach is currently implemented in the biggest french bank (BNP).

The approach is supported by a tool which convert business models to OAS then extends the specifications by adding http features.
This tool is called 'Swapi'.

The tool includes an http rules engine and check rules of an OAS but also among a set of OAS (for instance, a rule checks that a link in a response is consistent to the linked operation signature).

To be honest, I often think to myself when I design APIs: "How is it possible to design OAS in an other way?". This is the reason I would like to present this approach (and its relative tool to support it).

I can explain you the approach (powerpoint slides and/or show you a presentation in a real context)

This approach is also used to generate the 'Avro' schemas (and gRPC in a next future)

The adoption of GraphQL APIs in production is increasing. Sure, you can declaratively fetch the data you need, but could over fetching be dangerous? While teams use this query language to create fast, flexible APIs, they inadvertently expose their systems to new attack vectors in the process.

This session will cover the dos and don'ts of designing secure GraphQL APIs by highlighting case studies and the OWASP risks connected with them. The goal is to give you the tools you need to be proactive and plan for threats earlier in the API lifecycle. In addition, you'll also learn about the challenges and security risks that GraphQL APIs face when compared to other popular API specifications and standards.

Today, with the explosion of microservices and a plethora of protocols, ensuring in an automated manner that the API implementations actually adhere to their contracts is almost impossible. And on the other side, the consumers of these APIs have to hand-code the API stubs (poor man's service virtualization), with no guarantee that the stubs actually adhere to their OpenAPI specifications. All of these gaps manifest as integration bugs late in the cycle.

If these problems sound familiar, then this session is for you to understand how to leverage the very same OpenAPI specifications, so that they can be turned into contract tests and stubs without writing a single line of code.
Takeaways
Attendees will learn the following:

As an author of an OpenAPI spec, you would like to ensure that the API developer who will implement this API is adhering to the contract. Learn how to author OpenAPI specs which can verify that the API is implemented correctly.
As a consumer you often need to stub out your API dependencies while developing and testing your component. Learn how to set expectations that actually adhere to the contract, and thereby avoid late integration issues.

Target Audience
- CTOs / Heads of Engineering / Technology Leaders
- Dev Leads, Managers, Platform Engineering Architects
- Senior Developers, Automation Engineers and Build Experts

Pre-requisites
- OpenAPI or other similar API Specification Standards
- Basic understanding about Test Pyramid with Unit, Integration and End to End Tests
- Good level of understanding about Integration Testing - Purpose, Issues, etc.
- Service Virtualization and related issues
- Experience with Contract Testing will be a bonus