When creating a plugin for a OpenAPI description with no operationId, the plugin is created with no functions or runtime info about kiota HOT 10 OPEN

Do we have better ways to generate operation Ids based on the path? I feel it would be a lot more dev friendly.

from kiota.

@maisarissi what would you have as a placeholder?
I'm assuming the sliced description also needs the operationId to be set, correct?

from kiota.

They are not required. At runtime, random GUIDs will be generated to ensure their unicity.

from kiota.

so we don't need to change anything here?

from kiota.

We need to generate the functions in the plugin for sure. If they are not generated, they are ignored and won't get called.

from kiota.

ok so back to my previous question, I'm guessing we're using a guid as a placeholder. And I'm guessing the sliced description needs the same guid as operation id?

from kiota.

Maybe we could generate an operationId combining the endpoint with the HTTP method?
Something like: posts#GET could be posts-list, then posts/{posts-id}#GET could be posts-get, posts#PATCH posts-patch, posts/{posts-id}/comments#GET posts-comments-list, posts/{posts-id}/comments/{comment-id}#GET posts-comments-get and so on and so forth.

from kiota.

According to the validator, we would need the operationId to have the format ^[a-zA-Z0-9_]*$ (essentially number,digits and underscores). So, using something like posts-list would lead to validation error by the plugins lib and we would need to use underscores instead rather than the dash.

Another idea is that we can use the same logic Kiota uses for namespacing for a path and append the operation name at the end and separating them with underscores.
posts#GET => posts_get
posts/{posts-id}#GET => posts_item_get
posts/{posts-id}/comments#GET => posts_item_comments_get
posts/{posts-id}/comments/{comment-id}#GET => posts_item_comments_item_get

Back to the question by @baywet, we probably need to answer,

• Should the openApi file that is also generated/sliced from the original description at output also be updated with the added operationIds to match?
• Should we attempt to sanitize operationId for the sake of the validator if the original operationId does not match the plugin validation rules? (and update the openApi description as well?).

from kiota.

That's a great proposal @andrueastman. I think this would be optimal! For the questions:

• I'd say yes. The orchestrator will report on the operationIds used (not the function names from the plugin) and it'll be super useful for debugging later as devs will know which operation was called.
• This is a good question... And I think this is a fair way to ensure success. I'd vote for sanitizing both the plugin function names and the operationIds in a consistent manner. Basically "always" sanitize them to ensure full supportability.

from kiota.

Agree with @sebastienlevert.

• Yes, we should add the operationIds to the sliced OpenAPI description.
• If the existing operationId in the original OpenAPI document does not match with the validation rules, we should ensure success and sanitize them to successfully generate the sliced OpenAPI and the plugin.

from kiota.