Managing APIs with the Gloo Portal happens through the use of three resources: API Doc, API Product, and Environment. We go into more detail in the sections below, but the fundamental thing to understand is that Environments contain one or more API Products. API Products have multiple versions, each referencing API Docs and the operations they contain. API Docs define operations and are referenced in one or more API Product versions.
API Docs are a Kubernetes Custom Resource which packages the API definitions maintained by the maintainers of an API. Each API Doc maps to a single Swagger Specification. The APIs endpoints themselves are provided by backend services.
Each API Doc contains the definitions for the individual API operations available to be published as part of an API Product.
Developers can present the Gloo Portal administrator with their OpenAPI specifications without needing to know where the service backing the spec is deployed.
Read the full API Doc Spec here
API Products are a Kubernetes Custom Resource which bundles the APIs defined in API Docs into Versions. The API product can have multiple versions defined, each with their own references to API Docs and APIs selected from those API Docs.
Product owners specify the API Docs and operations they wish to bundle into a Version inside their API Products. The Versions also define the routing to reach an implementation of the APIs on a backend service.
Read the full API Product Spec here
An Environment represents information about a set of domains that serve a set of API Product versions. Environments control route creation and route-level configuration (e.g. rate limits, user access), which will be exposed to ingress traffic as well as published on a Portal UI.
Each Environment defines Usage Plans per API Product, specifying the tiers of access given to API clients, including how clients are authenticated and rate limited to the APIs they consume.
Read the full Environment Spec here