Client generation fails with null reference when operationId is not present

[sotetos]

The client generation currently uses the operation Id to determine the method name. This can be great since the operationId is unique, but it causes and error when using the default swagger generation in a new .net 6 project, which doesn't include it by default.

You can (and likely should) add it to the swagger document, but it would be great to add a default to Yardarm as well.

The null is created here: https://github.com/CenterEdge/Yardarm/blob/main/src/main/Yardarm/Generation/Tag/TagTypeGeneratorBase.cs#L29

[brantburnett]

What do you think the best approach would be for building the method name? I'm assuming based on the HTTP method and path? Something like $"{method}{SanitizePath(path)}" where we sanitize unsafe characters and pascal-case the path? So the operation name might end up something like "PutApiV1OrgId" for a PUT to "/api/v1/org/:id"? The main thing is we have to make sure we avoid name conflicts with other operations.

I think it also makes sense to implement this using DI with DefaultOperationNameProvider and IOperationNameProvider. That way consumers can override the behavior with a custom naming pattern.

[sotetos]

The method and the full path was my first thought. It might get a bit ugly depending on the path, but it should avoid conflicts between getting a single and getting a list. That was my main worry if we did anything with just the method and part of the path.

[brantburnett]

For the moment this is being addressed by #242. It's now skipping operations without IDs, but the consumer can implement a custom IOperationNameProvider as an extension and provider operation names themselves. I'm still evaluating what to do about further improving the default behavior when there is not operation ID present.