Is your feature request related to a problem? Please describe.
I'm trying to generate a client library from the OpenAPI spec generated from ash_json_api. Most code generators use the OperationId to name the methods for each operation. Because this attribute isn't included in the spec the generate code becomes very ugly and hard to work with.
Describe the solution you'd like
There are three main options here:
1) Provide a default operationId for all the endpoints generated within the Open API spec. This is preferred as it requires less configuration. The difficulty is making sure we can generate meaningful names by default. The OpenAPI spec also says the operationId a required to be unique across the whole spec.
2) Provide an option for the operationId to be manually provided when defining what actions should be exposed via the JSON API.
3) All of the above!
Describe alternatives you've considered
See above.
Express the feature either with a change to resource syntax, or with a change to the resource interface
Here's a snippet from the "getting started" tutorial with an additional option for the operationId.
json_api do
routes do
# in the domain `base_route` acts like a scope
base_route "/tickets" do
get Helpdesk.Support.Ticket, :read, operation_id: "getTicket"
index Helpdesk.Support.Ticket, :read, operation_id: "getTickets"
post Helpdesk.Support.Ticket, :read, operation_id: "createTickets"
end
end
end
With this option provided the OpenAPI spec would then include the operationId for each operation.
{
...
"paths": {
"/tickets": {
"post": {
"description": "create operation on ticket resource",
"operationId": "createTicket", # <-- This would be new!
...
}
}
}
What we've decided to go with for now is to add a name option that will be used as an operationId. It is not the same as deriving an operationId, but I don't see a good way to derive one currently :)
Is your feature request related to a problem? Please describe. I'm trying to generate a client library from the OpenAPI spec generated from ash_json_api. Most code generators use the
OperationId
to name the methods for each operation. Because this attribute isn't included in the spec the generate code becomes very ugly and hard to work with.Describe the solution you'd like There are three main options here:
1) Provide a default
operationId
for all the endpoints generated within the Open API spec. This is preferred as it requires less configuration. The difficulty is making sure we can generate meaningful names by default. The OpenAPI spec also says the operationId a required to be unique across the whole spec.2) Provide an option for the
operationId
to be manually provided when defining what actions should be exposed via the JSON API.3) All of the above!
Describe alternatives you've considered See above.
Express the feature either with a change to resource syntax, or with a change to the resource interface
Here's a snippet from the "getting started" tutorial with an additional option for the
operationId
.With this option provided the OpenAPI spec would then include the
operationId
for each operation.Additional context Link to the OpenAPI Spec that mentions
operationId
https://swagger.io/docs/specification/paths-and-operations/