| name | openapi-operations |
| description | OpenAPI operation rules 11-13 for naming, pagination, and responses |
API Specification - Operations (Rules 11-13)
Operation naming, pagination, and response patterns
Rule 11: Method Naming Pattern - NEVER Use 'describe'
operationId: getAccessToken
x-method-name: getToken
operationId: listAccessTokens
x-method-name: listTokens
operationId: describeItem
x-method-name: getAccessToken
x-method-name: getAccessToken
x-method-name: listUserItems
Rule: x-method-name must NOT contain the tag name, but operationId should be fully descriptive for global uniqueness.
🚨 CRITICAL: Parent vs Global List Operations
When organizing list operations, distinguish between sub-resource lists and global lists:
Sub-Resource Lists → ParentApi.listSubResources
When listing sub-resources of a parent, use the parent resource tag with listSubResources method name:
/organizations/{orgId}/users/{userId}/roles:
get:
tags:
- user
operationId: listUserRoles
x-method-name: listRoles
Global Lists → ResourceApi.list
When listing resources globally (not under a parent), use the resource tag with list method name:
/organizations/{orgId}/roles:
get:
tags:
- role
operationId: listRoles
x-method-name: list
Summary:
- Sub-resource (users/{userId}/roles) →
tags: [user], x-method-name: listRoles → userApi.listRoles()
- Global resource (/roles) →
tags: [role], x-method-name: list → roleApi.list()
Why: This pattern ensures that:
- Sub-resources are accessed through their parent API
- Global resources have clean
list() methods
- API organization matches resource hierarchy
- Each tag can have one
list method without conflicts
🚨 CRITICAL: Operation ID Consistency for Same Resource
When you have multiple operations for the SAME resource, the operationId must use the SAME resource name consistently:
paths:
/organizations/{organizationId}:
get:
operationId: getOrganization
/organizations:
get:
operationId: listOrganizations
paths:
/organizations/{organizationId}:
get:
operationId: getOrganization
/organizations:
get:
operationId: listOrgs
paths:
/users/{userId}:
get:
operationId: getUser
/users:
get:
operationId: listAccounts
Rationale: Consistency in naming makes the API predictable and easier to understand. If one operation uses "Organization", ALL operations for that resource must use "Organization" (not "Org", not "Orgs", not "Organisation").
Summary Text Rules
getItem → Summary: "Retrieve an item"
listItems → Summary: "Retrieve items"
- Use "Retrieve" for get/list operations
Rule 12: Pagination - MANDATORY for ALL List Operations
🚨 CRITICAL: ALL list* operations MUST be paginated using PagedResults
PagedResults Requirements
For TypeScript PagedResults generation, operation MUST have ALL 4 conditions:
- pageSize parameter (core type)
- pageNumber OR pageToken parameter (core type)
- links response header (core type)
- Response schema is array
components:
parameters:
pageSizeParam:
$ref: './node_modules/@zerobias-org/types-core/schema/params.yml#/pageSizeParam'
pageNumberParam:
$ref: './node_modules/@zerobias-org/types-core/schema/params.yml#/pageNumberParam'
headers:
linksHeader:
$ref: './node_modules/@zerobias-org/types-core/schema/headers.yml#/linksHeader'
paths:
/users:
get:
operationId: listUsers
parameters:
- $ref: '#/components/parameters/pageSizeParam'
- $ref: '#/components/parameters/pageNumberParam'
responses:
'200':
description: Successful response
headers:
links:
$ref: '#/components/headers/linksHeader'
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/User'
/users:
get:
operationId:
IMPORTANT: NEVER reference node_modules directly in paths. Always define in components/parameters and components/headers first, then reference the component.
Pagination Parameter Options
Define in components first, then reference:
components:
parameters:
pageSizeParam:
$ref: './node_modules/@zerobias-org/types-core/schema/params.yml#/pageSizeParam'
pageNumberParam:
$ref: './node_modules/@zerobias-org/types-core/schema/params.yml#/pageNumberParam'
pageTokenParam:
$ref: './node_modules/@zerobias-org/types-core/schema/params.yml#/pageTokenParam'
Option A: Page Number (offset-based)
parameters:
- $ref: '#/components/parameters/pageSizeParam'
- $ref: '#/components/parameters/pageNumberParam'
Option B: Page Token (cursor-based)
parameters:
- $ref: '#/components/parameters/pageSizeParam'
- $ref: '#/components/parameters/pageTokenParam'
Handling API-specific pagination:
- If API uses
cursor → Map to pageToken in components
- If API uses
offset → Calculate pageNumber (offset / pageSize)
- If API uses custom params → Map them to standard params
NEVER use custom pagination parameters directly:
- ❌
since, offset, limit, cursor - Map to core params
links Response Header (MANDATORY)
Define in components first:
components:
headers:
linksHeader:
$ref: './node_modules/@zerobias-org/types-core/schema/headers.yml#/linksHeader'
Then reference in operations:
responses:
'200':
headers:
links:
$ref: '#/components/headers/linksHeader'
WHY: PagedResults provides type-safe pagination with next/previous links
Rule 13: Response Codes - 200/201 Only
NEVER add 40x or 50x error responses - Framework handles ALL errors
responses:
'200':
description: Successful response
content:
application/json:
schema:
$ref: '#/components/schemas/Resource'
responses:
'200':
description: Success
'401':
description: Unauthorized
'404':
description: Not found
'500':
description: Server error
WHY: Framework's error handling automatically converts HTTP errors to typed exceptions. Adding error responses to the spec:
- Creates unnecessary code generation
- Duplicates framework error handling
- Makes specs harder to maintain
Operation Naming Quick Reference
| Operation Type | operationId Pattern | x-method-name | Summary |
|---|
| Get single | get{Resource} | Without tag | "Retrieve a {resource}" |
| List multiple | list{Resources} | Without tag | "Retrieve {resources}" |
| Create | create{Resource} | Without tag | "Create a {resource}" |
| Update | update{Resource} | Without tag | "Update a {resource}" |
| Delete | delete{Resource} | Without tag | "Delete a {resource}" |
| Search | search{Resources} | Without tag | "Search {resources}" |
NEVER: describe{Resource} - This is forbidden!
Validation Checklist
Before finalizing operations:
These operation rules ensure consistency and framework compatibility across all modules.