-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C# Methods as alternative to Indexers and QueryParameters #4393
Comments
Hi @RandomBuffer 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. |
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 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). |
Thanks for the additional information. 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! |
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 |
Thanks for letting us know. Can you please open an issue about this here https://github.com/MicrosoftDocs/openapi-docs |
Have opened issue. Noting happy with the C# Fluent syntax, its just having an alternative to indexers like |
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? |
Ok to close, thanks |
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.The text was updated successfully, but these errors were encountered: