1105 progenitor requires operationid to be set #1110
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR modifies missing
operationId
handling from default-deny to default-generate. At this point there is noGenerationSetting
for this to be configured, I expect the PR not to go through because of that (to add aGenerationSetting
field I feel there is more discussion needed, however, I'm happy to it once it's clear how that is desired).The algorithm used here tries to apply 'smart' heuristics and is, of course, opinionated. To capsule it all I introduced a the new module
opid
with a structOperationIds
, which stores mappings between the path method tuple and theoperationId
(generated or manually set).The changes to
lib.rs
try to be minimal, most logic is inopid.rs
, as well as most unit tests.validate_openapi()
now runs two passes:operation_id
is present, store that in theOperationIds
struct, together with their path/method mappingOperationIds
is stored in theGenerator
instance.Later, when requiring an
operation_id
, these are pulled from theOperationIds
struct (rather than theOperation
object directly as it has been previously).Step 2 in above uses an algorithm to generate the name, which also handles collisions with both present
operationIds
and also its own generated ones.The name generation algorithm is described in detail in the
OperationIds::gen_operation_id()
method in theopid.rs
file. The basic idea is that names derive from HTTP path and method, which are unique in combination. The path is stripped of non alphanumeric characters and lowercased, and the HTTP method is appended with a '_' prefix.So 'GET /foo/bar' becomes
foo_bar_get
. There are more special cases which are documented and covered by the unit tests.Thanks for reading all this, hope it helps with reviewing the PR :)