API-Designer: Duplicate operationIds in the swagger definition

It's the same for two methods with different count of parameters, e.g.

builder.AddMethod(Method.Define("obj/{id}").WithParameter("id", isInQuery: false).HandleGet(qr => "single obj"));
builder.AddMethod(Method.Define("obj/{id}/{id2}").WithParameter("id", isInQuery: false).WithParameter("id2", isInQuery: false).HandleGet(qr => "single sub-obj"));

I investigated a bit further and it seems that every part of the path that is like {...}, is ignored in the generation of the operationId (in the generated swagger.json).
Thus the above definitions both lead to the operationId "CCC_obj_get"..

Hi,

The {...} parts of your path are not exactly ignored, but as they are parameters, they are not part of the method name.

In your situation, the two methods lead to the same operation ID.

The best thing to do is to disambiguate the methods by assigning a ClientSuffix:

Method.Define("obj/{id}/{id2}")
...
.With(m => m.Settings.ClientSuffix = "byid")

This will cause the TypeScript generator to create an operation ID "CCC_obj_get_byid".

Regards

Hanno

Hi Hanno,

thanks for answering and it looks promising - but I cannot find a Route property on IMethod.. (8.1.5)

Regards, Wolfgang

Thanks for pointing out my mistake -- I've amended the code above.

I cannot find a ClientSuffix-Property (or something similar) on IMethodSettings either..

In addition, paths like a/{x}/b/{y} leads to an operationId of XYZ_a_GET while a/{x}/b/{y} leads to XYZ_a_b_GET.

Overall - I think that the generation of the Id too often leads to ambiguous results. You should consider to include the parameter names as well.

Hello Wolfgang,

You are right -- my apologies for mixing up versions. The ClientSuffix property was added in 8.2 and is not available in 8.1.x.

As we rely on NSwag to generate the method names for the API client, there may be limitations to the generation of operation IDs ...

Thanks for sorting things out. So I have to wait until we can update.

The latter part with NSwag is not that clear to me. The operation ID has to be unique for every endpoint. By not using the parameters at all and ignoring fixed parts between first and last parameter ("b" in "a/{x}/b/{y}"), you get (unsolvable) ambiguities with surprising ease and this actively prevents writing a clear/conventional api.