Choreo Connect as a Standalone Gateway¶
Choreo Connect can be used as a standalone Gateway without the API Manager as the Control Plane. Choreo Connect is considered to be in standalone mode when
control-plane is disabled in the config. In standalone mode,
- APIs can be deployed via apictl (CLI Tool).
- apictl can be used to create API projects based on an OpenAPI definition.
- These API projects can be directly pushed to the adapter, which will deploy the APIs in the Enforcer and the Router.
When Choreo Connect is used as a standalone Gateway, you can connect it to an external Secure Token Service (STS), which will provide signed JWTs, and Choreo Connect will validate those JWTs in the incoming requests.
Defining an API with OpenAPI Specification¶
Defining Gateway specific properties¶
Not all properties required for an API Gateway can be defined in the OpenAPI specification since it is meant to be a descriptor of an REST endpoint such as a backend service or microservice. However, in standalone mode, a developer can define the following:
Different types of endpoints
Retries and timeouts
and many other Gateway specific features per API or per resource right within the OpenAPI Specification. Choreo Connect utilizes OpenAPI Specification's vendor extensions for this purpose.
The list of vendor extensions Choreo Connect introduces can be found here.
Defining base path and backend URLs¶
In Choreo Connect, base path is used to group all HTTP resources (paths) of an API under a single context. This is how Choreo Connect logically separates one API from another. Choreo Connect resolves base path and the backend URLs (also known as Endpoints) from the OpenAPI definition as follows.
With Swagger 2.0¶
The Swagger 2.0 specification defines a way of providing the base path and the host of the service. If your Swagger definition specifies the combination of schemes, basePath and host attributes, Choreo Connect drives the backend service URL from host and schemes, and derives the base path using the base path attribute.
With OpenAPI 3.0¶
The OpenAPI 3.0 specification defines a way of providing the server URL of the API. Choreo Connect derives the base path and the backend service URL using this servers object. For example, when the last server URL is defined as
http://test.com/v2, Choreo Connect will add this URL as one of the backend URLs and set
/v2 as the base path (context)
The above behavior exists since WSO2 supports creating an API project simply by pointing to an OpenAPI definition. To simplify defining these attributes a little more, WSO2 recommends using the following two WSO2 specific extensions in the OpenAPI definition.
The value for
x-wso2-basePath will be used as the base path there onwards. The extension
x-wso2-production-endpoints can refer to the backend URLs (actual backend service implementation of the API).
x-wso2-production-endpoints especially becomes mandatory when Defining Gateway specific properties as mentioned above.
x-wso2-basePath is not present in the OpenAPI, the base path is derived from the servers object. For an example, when the server's URL is defined as below, Choreo Connect will expose the API with the base path (or context)
OpenAPI servers object
servers: - url: https://api.example.com/v1
Therefore, editing the last part of the servers URL(
/v1) will also change the base path. Yet, if you use the extension
x-wso2-basePath, the base path will not change when you update the servers.
Also, you can define endpoint configurations globally using the
x-wso2-endpoints extension as explained here. Then, endpoints available under the
x-wso2-endpoints can be used with
x-wso2-production-endpoints. For a detailed example, see the detailed sample for endpoint definitions..
Updating the API¶
APIs can be updated as long as Choreo Connect is not meant to be run as an Immutable Gateway. To learn more about running Choreo Connect as an Immutable Gateway, click here.
Step 1 - Update the relevant definition file inside the existing API project¶
Update the file inside the
Definition folder with any API related change. The following values can be updated by editing the
- API name (Title)
- Lifecycle status (e.g.,
- API type (e.g.,
- Backend security
- API name (Title)
The version must not be edited once deployed because in the standalone mode, the version represents the identity of the API. Therefore, editing these values will make the API behave as a new API while continuing to keep the previous version of the same API.
Step 2 - Redeploy the project¶
Use apictl to override the API using the
apictl mg deploy command with the override flag (
Choreo Connect supports the following OpenAPI Extensions. You can use these extensions to override information with regard to API specifications.
||Base path that the Gateway uses to expose the API.||Optional → API level only|
||Specifies the actual backend of the service.||Optional → API/Resource level|
||Specifies the sandbox endpoint of the service if available.||Optional → API/Resource level|
||Specifies the rate limiting for the API or resource.||Optional → API/Resource level|
||Specifies the Cross-Origin Resource Sharing (CORS) configuration for the API.||Optional → API level only|
||Enables the resource to be invoked without authentication.||Optional → API/Resource/Operation level|
||Specify the authorization header for the API to which either bearer or basic token is sent||Optional → API level only|
- If you want to expose an API or a resource without security, you can use the
x-wso2-disable-securityextension. You can find more information about this extension from here.
- Choreo Connect also supports the
"x-auth-type": "None"option to disable the security. This extension has a different functionality when run with WSO2 API Manager and can have the following values which are not supported in standalone mode.
- Application & Application User
- Application User
See the petstore_basic.yaml file to view an example on how these OpenAPI extensions are used in an OpenAPI definition.
Subscription validation for self-contained JWTs¶
To authorize an API request with the self-contained JWT token under an issuer with subscription validation, the API name and version should be listed under
subscribedAPIs claim of the JWT token.