Add support for enum path parameters

[MatthiasNistl]

See #4340.
This PR intends to add support for Enums as path parameters. The created Enums can be used as indexers in the request builders.

As far as I understand existing Kiota clients can still use primitive types (strings) as indexers, but they might be marked as deprecated (This indexer is deprecated and will be removed in the next major version. Use the one with the typed parameter instead.).

[MatthiasNistl]

@microsoft-github-policy-service agree

[baywet]

Thanks for the contribution!

Have you tested the generated code can handle serialization of the values properly? Especially when the symbol is different from the value?

[baywet]

shouldn't we consider any or one of at well? this seems like it's special casing for one of the scenarios you ran into

[MatthiasNistl]

You are probably right. We generate our API spec from code, and all Enums references have been generated with "AllOf", but it makes sense to check AnyOf and OneOf, too.
I have now added an extension that uses the already existing Func to flatten the subsequent schemas. Not sure if this is the correct way to achieve this?

[MatthiasNistl]

Thanks for the contribution!

Have you tested the generated code can handle serialization of the values properly? Especially when the symbol is different from the value?

@baywet I have only tested generated code for C# so far. The Enums are serialized according to their EnumMember Value, which is identical to the API specification (just like when an enum is generated for a request model). The Enum symbols might be different since they always start with an uppercase letter, but this seems to be irrelevant during serialization. Both as path parameter and in the request body the enums are serialized according to their Enum value, so at least in my use cases this seems to work.

Unfortunately I don't know how other languages handle enums or what else needs to be considered for other target languages 😟
Maybe someone else can check this?

[baywet]

@MatthiasNistl Thank you for the additional information.

I think the first step here would be to demonstrate that we have sufficient unit test coverage for enums in the kiota libs.

For example:

• java : https://github.com/microsoft/kiota-java/blob/867ee572f58fdbb5f3913b0f743b5fe390691748/components/abstractions/src/test/java/com/microsoft/kiota/RequestInformationTest.java#L358
• dotnet : https://github.com/microsoft/kiota-dotnet/blob/ae9a82ff2d1445ad2f1ef26a9d9e918a402b8a26/tests/abstractions/RequestInformationTests.cs#L613

The repositories structure is similar, so you should get around even without the knowledge of the language. And you can ignore ruby and swift since they were never completed.

[MatthiasNistl]

@baywet Unfortunately I'm not quite sure what you mean. I see that the same tests for Enums exist in their own language-specific variant in most of the repositories, for example:

• go: https://github.com/microsoft/kiota-abstractions-go/blob/main/request_information_test.go#L261
• python: https://github.com/microsoft/kiota-python/blob/main/packages/abstractions/tests/test_request_information.py#L179
• typescript: https://github.com/microsoft/kiota-typescript/blob/main/packages/abstractions/test/common/requestInformation.ts#L131
• dart: https://github.com/microsoft/kiota-dart/blob/main/packages/microsoft_kiota_abstractions/test/request_information_test.dart#L217

It seems to me like enums are pretty well covered accross the libs.
However, I fail to understand how exactly the tests relate to the changes in this PR or how they might be affected. Without really knowing kiota I understand that there is an additional abstraction layer between the core and the language-specific libs. How can I ensure with confidence that the changes here do not introduce any issues down the road?