Currently no operations in openapi.yaml have operationId fields. This is a recommended field in the OpenAPI specification, and its absence forces every code generation consumer to invent their own naming from the path.
Different tools produce different results for the same endpoint, making generated code inconsistent across the ecosystem (OpenAPI Generator, Orval, hey-api, Autorest, etc.).
Example
Current:
/redfish/v1/AccountService/Accounts/{ManagerAccountId}:
get:
responses:
'200':
content:
application/json:
schema:
$ref: http://redfish.dmtf.org/schemas/v1/ManagerAccount.v1_14_1.yaml#/...
description: The response contains a representation of the ManagerAccount resource
delete:
responses:
# ...
patch:
responses:
# ...With operationId:
/redfish/v1/AccountService/Accounts/{ManagerAccountId}:
get:
operationId: getAccountServiceAccountById
responses:
# ...
delete:
operationId: deleteAccountServiceAccountById
responses:
# ...
patch:
operationId: patchAccountServiceAccountById
responses:
# ...More Examples - Enhanced Id generation
| Path |
Generated operationId |
/redfish/v1 |
getServiceRoot |
/redfish/v1/Systems/{id}/Storage/{id} |
getSystemStorageById |
/redfish/v1/AccountService/Accounts |
getAccountServiceAccounts |
/redfish/v1/Managers/{id}/Actions/Manager.Reset |
postManagerReset |
postManagerReset is certainly more human friendly compared to postRedfishV1Managers_Id_ActionsManagerReset
Impact
Without operationId, consumers must implement their own naming logic. For example, our project maintains ~25 lines of path-parsing code to generate clean operation names from the path structure (singularizing resource names, stripping the /redfish/v1 prefix, replacing {param} with ById, etc.). Every Redfish consumer does some variation of this independently.
DMTF's tooling already knows the resource names — operationId could be auto-generated during the spec build process.
Currently no operations in
openapi.yamlhaveoperationIdfields. This is a recommended field in the OpenAPI specification, and its absence forces every code generation consumer to invent their own naming from the path.Different tools produce different results for the same endpoint, making generated code inconsistent across the ecosystem (OpenAPI Generator, Orval, hey-api, Autorest, etc.).
Example
Current:
With
operationId:More Examples - Enhanced Id generation
/redfish/v1getServiceRoot/redfish/v1/Systems/{id}/Storage/{id}getSystemStorageById/redfish/v1/AccountService/AccountsgetAccountServiceAccounts/redfish/v1/Managers/{id}/Actions/Manager.ResetpostManagerResetpostManagerResetis certainly more human friendly compared topostRedfishV1Managers_Id_ActionsManagerResetImpact
Without
operationId, consumers must implement their own naming logic. For example, our project maintains ~25 lines of path-parsing code to generate clean operation names from the path structure (singularizing resource names, stripping the/redfish/v1prefix, replacing{param}withById, etc.). Every Redfish consumer does some variation of this independently.DMTF's tooling already knows the resource names —
operationIdcould be auto-generated during the spec build process.