C# Methods as alternative to Indexers and QueryParameters

[ghost]

Thanks for this project, it worked out of the box with Swashbuckle. It would be awesome if we could generate methods for C# as alternative to indexers just like the Java example in Indexers. The method syntax seems more natural to use.

Same goes for QueryParameters having something like x.QueryParameters.Select("id", title") would be cool.

[baywet]

Hi @RandomBuffer
Thanks for using kiota and for reaching out.

On indexers: why do you think methods would be better than indexers? Isn't it closer to language semantics after all?

On query parameters: using a method to set the select value is probably to a fluent API design than using the setter with =. This would require generating a getter method as well, and a backing field. It'd probably result in "heavier" binaries. Besides the style consistency, do you see any other benefit to such change?

To be fully transparent, unless we get overwhelming demand for those two, we're probably unlikely to make any of those changes any time soon as they'd represent source breaking changes.

[ghost]

Hi @baywet for both its mostly readability and help from Intellisense without resorting to looking at the generated code or Swagger to figure out the path and parameter info. For example Intellisense will help me out with var requestBuilder = todoClient.TaskLists("taskListId").ToDos("todoId").AssignedTo;.

Also some interesting feedback in https://devblogs.microsoft.com/microsoft365dev/tailored-sdk-experiences-via-kiota-now-generally-available/#comment-191

Btw I mentioned Kiota here dotnet/aspnetcore#54598 (comment).

[baywet]

Thanks for the additional information.
The Java equivalent of that is actually (casing aside)

todoClient.TaskLists.ById("taskListId").ToDos.ById("todoId").AssignedTo

So each fluent API segment maps to a path segment on the API.

The comment you've shared outlines a lack of design documentation on our side. The fluent API pattern still shows some relation to HTTP, and the API segmentation, but that's a feature. This is because it works consistently across any API, large or not, deep (segmentation) or not. The OperationId based approach as too many short comings (starting with the fact they are not required in the OpenAPI spec).

Thanks for bringing kiota up!

[ghost]

Looks like the docs are not upto date as I copied my example from the Java example there https://learn.microsoft.com/en-us/openapi/kiota/request-builders#indexers

[baywet]

Thanks for letting us know. Can you please open an issue about this here https://github.com/MicrosoftDocs/openapi-docs

[ghost]

Have opened issue. Noting happy with the C# Fluent syntax, its just having an alternative to indexers like ById() example above would be sweet.

[baywet]

Thanks!

Again, noted, but we're unlikely to change this at this point unless we get overwhelming demand for it.

Anything else or is it ok to close this issue?

[ghost]

Ok to close, thanks