Resource Type Configuration and Naming Conventions

[Tharsanan1]

Resource Type Configuration and Naming Conventions

Resource Configuration Structure

When creating a new resource type, the resource configuration should follow this standard structure:

apiVersion: <component-type>.api-platform.wso2.com/<version>
kind: <resource-type>
metadata:
  name: <resource-name>
spec: <configuration of the resource>

Component Type Naming Convention

The <component-type> field indicates which component of the platform the resource belongs to. Use the following conventions:

Component Type Values

• gateway - For resources specifically designed for the standard/normal API gateway
• ai-gateway - For resources specifically designed for the AI gateway
• controlplane - For resources designed for the control plane

Examples:

apiVersion: gateway.api-platform.wso2.com/v1alpha1
kind: RestApi

apiVersion: ai-gateway.api-platform.wso2.com/v1alpha1
kind: LlmProvider

apiVersion: controlplane.api-platform.wso2.com/v1alpha1
kind: Subscription

Resource Type Naming Convention

The <resource-type> field must adhere to the following naming conventions to ensure consistency across the platform:

1. Capitalization for Multi-Word Resources

When a resource type contains multiple words (e.g., WebSocket) or multiple acronyms (e.g., RestApis):

• The first letter of each word or acronym should be capitalized
• All other letters should be lowercase

Examples:

• WebSocket (not Websocket or WEBSOCKET)
• RestApi (not RESTAPI or restapi)
• ApiKey (not APIKey or Apikey)

2. API Type Resources

For resources that represent API types (such as REST, GraphQL, WebSocket, gRPC), the name must be postfixed with Api:

Examples:

• RestApi
• GraphqlApi
• WebSocketApi
• GrpcApi
• SoapApi

3. Non-API Resource Types

For other types of resources that are not API types (such as policies, backends, rate limits, authentication configurations):

• Follow the same capitalization rules as above
• Do not include the Api postfix
• Use descriptive, singular nouns that clearly indicate the resource's purpose

Examples:

• Subscription
• LlmProvider

Complete Examples

Standard Gateway API Resource:

apiVersion: gateway.api-platform.wso2.com/v1alpha1
kind: RestApi
metadata:
  name: petstore-api
spec:

AI Gateway API Resource:

apiVersion: ai-gateway.api-platform.wso2.com/v1alpha1
kind: LlmProvider
metadata:
  name: llm-proxy-api
spec:

Control Plane Resource:

apiVersion: controlplane.api-platform.wso2.com/v1alpha1
kind: Subscription
metadata:
  name: basic-subscription
spec:

[nuwand]

Sounds good.

[RakhithaRR]

What would be the plan for managing the apiVersion here? Do we increase that every time there is a change to the resource spec? Multiple kinds can fall under a single API version. In that case do we change the versions independently for each kind?

[Krishanx92]

Change ai.gateway --> gateway

Complete Examples

Standard Gateway API Resource:

apiVersion: gateway.api-platform.wso2.com/v1alpha1
kind: RestApi
metadata:
  name: petstore-api
spec:

AI Gateway API Resource:

apiVersion: gateway.api-platform.wso2.com/v1alpha1
kind: LlmProvider
metadata:
  name: llm-proxy-api
spec:

Control Plane Resource:

apiVersion: controlplane.api-platform.wso2.com/v1alpha1
kind: Subscription
metadata:
  name: basic-subscription
spec: