autorest: Follow-up for 653 Issue - Duplicate operationIds and underscore symbol - AutoRest has a bug around underscores
The issue #653 mentions an article about how to solve the problem with duplicate operationIds generated by Swashbuckle.
Duplicate operationId is not only Swashbuckle fault, Autorest can’t parse OperationId with more than one underscore correctly: so if your operationIds are :
"operationId": "Debug_Get",
"operationId": "Debug_GetByid",
"operationId": "Debug_ReceiveCommandByjsonData",
"operationId": "Debug_Get2Bymodel",
Autorest will work fine.
if you have some prefixed operationIds like (they are still unique though):
"operationId": "V1_Debug_Get",
"operationId": "V1_Debug_GetByid",
"operationId": "V1_Debug_ReceiveCommandByjsonData",
"operationId": "V1_Debug_Get2Bymodel",
Autorest fails to interpert these operationIds correctly - you’ll get a message
error: [FATAL] Error generating client model: Found operation objects with duplicate operationId ‘V1_Debug’. OperationId must be unique among all operations described in the API.
It was mentioned by @VR-Architect in #651 that it was fixed in v.0.14, but I checked valid swagger.json with both v.0.15 and v.0.14 and they are both failing to parse operationid when it has more than one underscore.
As soon as I update swagger definition to have operationId with just one underscore - it works fine.
It seems like an issue in AutoRest operationId parsing.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 22 (10 by maintainers)
If you need a case study for why verb_another_verb_whatever etc is going to continue then look no further than EVE Online - https://esi.tech.ccp.is/latest/swagger.json?datasource=tranquility
Point is if you’re going to walk into this entire “AutoRest” with the attitude of “if its not within our bubble, its not at all” then you’ve learned nothing from our days with SOAP.
Deferring for “stable” is also a weak avoidance behaviour. Address the issue and keep this open until you’ve confined the solution to a reasonable approach. GitHub isn’t Microsoft Connect and the days of when we used to triage problematic issues like this with “as per design” or “deferred to x” isn’t going to work with OSS space.
This is how you bank hate debt with developers.
I have never been a fan of the implicit decision in AutoRest to parse the
operationId
and use that as the basis for choosing “method-group” and “method” names. Seems kinda hacky to me to begin with.AutoRest is replete with implicit assumptions … such is the life when you inherit a codebase.
Later this week, we’re starting work on an overhauled configuration system that will make it simpler to override behavior in the code generation process (by providing an external file that contains the information to the generator), without having to edit the swagger file itself (which helps not only @bowman-jm 's scenario of an automated swagger generation, but others who don’t want to pollute the swagger with information that doesn’t really describe the wire-behavior)
It should not be terribly difficult to provide an override for
methodgroup
andmethod
name on a per-operation basis in there.We should be using Tags first, then OpId.
Though, the way @centur describes the Verb and Noun both containing underscores worries me a bit. It seems like this will end up with some pretty nasty names. How do you decide where the noun and the verb are with something like:
Nou_n_V_er_b
? If you have undefined number of_
, then building nice names from OperationIds is going to be pretty gnarly. Do you then got to where Capitalizations are? I don’t really want to play that game, b/c I don’t think we will ever make everyone happy.I think we should do the following:
_
, and the operation name is the language normalized form of the substring after the first_
.The
So… there is a way to handle this now without changing AutoRest itself (and at this point, I’m not inclined to revisit decisions made prior to me taking over the project).
If you switch to using a configuration file for running AutoRest (use
autorest init
to get an example) , you can use adirective
to modify the model.Make a readme.md in your folder something like this:
and then run
autorest --csharp readme.md
and it will use the first tag for each operation as the group name.