San-43 commented on PR #5744:
URL: https://github.com/apache/fineract/pull/5744#issuecomment-4196799333
@edk12564, a quick thought – and I might be missing some background – but
wouldn't it be better to handle this within the OpenAPI generation process?
Perhaps a deterministic fallback for those missing `operationIds` would be the
way to go.
Something like:
- keep explicit `operationIds` where we want to preserve
public/client-facing names
- generate stable fallback IDs for any endpoint that doesn't define one
My concern with adding them manually across resources is that it fixes only
the endpoints touched here, while the underlying instability is still there for
any endpoint that doesn't have an explicit `operationId`. That feels harder to
maintain over time than fixing it once in the generation step.
I think the more robust fix is build-time and centralized: let
`:fineract-provider:resolve` generate the spec as today, then add a
normalization/validation step on the generated `fineract.json` that:
- preserves existing explicit `operationIds` unchanged
- generates deterministic fallback IDs only for missing ones, based on `path
+ http method`
- fails the build if the final `operationIds`are duplicated
That would solve the full problem for all endpoints, including future ones,
without requiring a long tail of manual annotation updates. For example,
`/v1/groups/{groupId}/clients + post `could deterministically become
`groups_groupId_clients_post`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
