When using SingleClientFromPathSegments , client methods are susceptible to change since NSwag will only include the HTTP method in client method names when there is a name conflict, e.g., if there is a GET and a POST method with the same signature.
So, if there is no signature conflict for a method and another endpoint is added with the same signature but a different HTTP method, the original client method name will change, i.e., it will subsequently include the HTTP method in its name.
E.g. if only a GET method exists for the endpoint Document, this would generate a DocumentAsync client method, but if a POST method were added, the DocumentAsync client method name would change to DocumentGetAsync.
This means that method signatures in a newly generated client always need to be compared to the ones in an existing client to detect whether any client method signatures should have changed.
Changed method signatures will then need to be modified accordingly in any consuming code, resulting in a bit of a maintenance nightmare.
This could be fixed by adding a setting, e.g., AlwaysIncludeHttpMethodInClientMethodNames.
Thanks for a great tool, except:
When using
SingleClientFromPathSegments, client methods are susceptible to change since NSwag will only include the HTTP method in client method names when there is a name conflict, e.g., if there is a GET and a POST method with the same signature.So, if there is no signature conflict for a method and another endpoint is added with the same signature but a different HTTP method, the original client method name will change, i.e., it will subsequently include the HTTP method in its name.
E.g. if only a
GETmethod exists for the endpointDocument, this would generate aDocumentAsyncclient method, but if aPOSTmethod were added, theDocumentAsyncclient method name would change toDocumentGetAsync.This means that method signatures in a newly generated client always need to be compared to the ones in an existing client to detect whether any client method signatures should have changed.
Changed method signatures will then need to be modified accordingly in any consuming code, resulting in a bit of a maintenance nightmare.
This could be fixed by adding a setting, e.g.,
AlwaysIncludeHttpMethodInClientMethodNames.