Motivation

Orchestration is particularly important when it comes to dealing with distributed architecture styles like microservices. At its core, orchestration is a pattern that favors a centralized application workflow. The OpenAPI Specification allows the description of a microservice remote API called from a workflow.

Operation state and OpenAPI REST function are expected to be one of the most used constructs in serverless workflows

Goal

Enable orchestration of OpenAPI microservices in workflows

Scenarios

As a developer, I need to combine serverless functions / services / containers to build a serverless application

As a developer, I need to combine knative services and other kube deployed services to build a workflow

Expected outcomes

Workflows use REST functions based on OpenAPI by default

Workflows can use OpenAPI description files from  URLs or a file system

Workflows can be defined with operation states which refer to supported function types (rest, expression - other types are tracked in other requirements)

HTTP Callback requests in Operation state are out of scope (tracked separately)

Out of scope

Service discovery of OpenAPI services (SRVCOM-1839)