Does the dev team want failing API examples?

[conficient]

I tried out Kiota when I saw it listed as a code generation method in the REST API Client Code Generator.

I tried using Kiota to generate C# for accessing the supplier's OpenAPI specification. It failed in a few areas (e.g. dashes in class names, etc), so I moved on to using NSwag which I'd used before.

So if you're looking for complex APIs to test with, this might be one to try: https://raw.githubusercontent.com/creditsafe/connect-docs/master/cs_connectv1-15.json

[baywet]

Thanks for trying kiota and for the feedback. Yes we want to hear about hurdles as we're heading to GA and in a quality phase.
v0.11.0 already contains multiple fixes for naming conventions. I believe the version that @christianhelle originally integrated was 0.10.0. If that is the case, and provided that Christian is willing to ship an update, would you mind trying it again?

[baywet]

(alternatively you could install the dotnet tool with dotnet tool install -g Microsoft.OpenApi.Kiota --prerelease and try the CLI experience)

[christianhelle]

My extension REST API Client Code Generator attempts to do same day releases with the code generators it supports. So when OpenAPI Generator, NSwag, or Kiota has a new release, I will make a new release as well.

v1.6.94 uses Kiota 0.10.0 and v1.6.96 uses Kiota 0.11.0

Before I publish a release, I run a comprehensive set of regression tests against the Swagger Petstore example v3 and v2 OpenAPI spec that generates code then build it on all the supported build agents in Github Actions

[christianhelle]

From v1.6.96 of the REST API Client Code Generator I include the version of the underlying code generator in the context menu

Something like this:

[conficient]

Excellent tool, many thanks! I'll have another go with the updated version

[conficient]

Upgraded to Kiota v0.11.0 and the codegen still fails - mainly due to ambiguous result types (two different results, same name). 4,881 errors for this API. I don't know if this is because the API is badly written or if Kiota isn't handling the scenarios correctly:

[christianhelle]

@conficient if you don't mind sharing your REST API Client Code Generator support key then I can probably find some extended diagnostic information

You can find your support key in the options page:

[conficient]

Key is d5c314c

I don't think your excellent tool is the issue here, I suspect it's either edge cases that Kiota isn't handling, or the API itself isn't well formed. NSwag works fine for the same source.

[baywet]

Thanks for the feedback here. @andrueastman can you have a look at this description and let us know whether the issue is specific to C# or to the core generation engine or to the description please?

[darrelmiller]

Hey @conficient , First of all, let me answer your primary question, yes absolutely we want to know about these failing cases. Thank you for taking the time to open this issue. This OpenAPI document is full of interesting challenges.

The first one issue is that it is failing our standard OpenAPI validation.

1Declared path parameter "investigationId" needs to be defined as a path parameter at either the path or operation level [#/paths/1protect1investigations~1{InvestigationId}~1results/get/parameters/1/in]~1results/get/parameters/1/in]

This one is puzzling because I don't see the error. I'm going to need to trace through the OpenAPI.Net validation code to see why this is giving an error.

I did get a lot of errors from the generated code when using the Kiota commandline, but I didn't get the ambiguous references errors that you go.

It looks like all the errors I got come down to these two main issues:

We currently do not generate a valid type for this. It is a bit of a strange way of defining an enum, but we should find a way to emit this.

   "Connect.Identity.Gender": {
        "description": "Below is a list of Definitions for the ENUM\n* 0 - Unknown\n* 1 - Male\n* 2 - Female\n",
        "enum": [
          0,
          1,
          2
        ],
        "type": "integer",
        "format": "int32"
      },

This kind of error was the source of not generating multiple types correctly including ReasonCode, AmlResultCode and Product.

The second issue is related to the fact that we don't handle schema properly.

"content": {
              "application/json": {
                "schema": {
                  "type": "string",
                  "format": "binary"
                }
              },

Again it is a fairly strange way to describe "application/json". Interestingly, NSwag maps this to a "FileResponse". It is possible that it determines this based purely on the format value. I think this is something where we could just return a Stream or byte[].

I don't think these issues are going to be too hard to fix. Anyway, thanks again for reporting them.