Open maisarissi opened 1 month ago
Tasks:
Only authorization code are supported as OAuth grant flows
API Key in custom headers, query params or cookies are not supported
Dual authentication flows (API Key AND OAuth token) for single API endpoint are not supported
Can be resolved with https://github.com/microsoft/kiota/issues/5071
I do have a bunch of questions about those rules...
Nested objects in response or parameters in API methods are not supported
What qualifies as nested object? an inline object type definition? or are you referring to properties that are of object types in general? (e.g. assigned licenses for user in Graph)
Polymorphic references in open API spec (oneOf, allOf, anyOf) are not supported
This is how we define inheritance (entity<-directory object<- user), which would in effect rule out most API definitions out there. We need to be much more specific here.
Circular references in open API spec are not supported
Likewise we have plenty of those in Microsoft Graph. E.g. a User has a manager property which is a user... Also should we consider multiple degrees of separation? (e.g. user.memberof ->group, group.members -> user)
Only authorization code and PKCE are supported as OAuth grant flows
Providing examples would help here.
API Key in custom headers, query params or cookies are not supported
Examples please.
Dual authentication flows (OAuth/Entra SSO + http Bearer token) for single API endpoint
Examples please.
OpenAPI descriptions needs to be 3.1.0 or previous versions
Considering 3.1.0 is not supported yet by OAI.net we should revisit this one for our current timelines.
Server url should be an absolute url with https protocol
Or in simple terms "should start with https://, case insensitive"
@maisarissi Shall we move it from Proposed to Todo? (meaning, is it a must-have for GA?)
@baywet I've added the examples and details around the validations in each of the new issues created.
After talking to @darrelmiller, I've created validation issues in the validation library. On top of the validations in the validation lib, linked to this epic, In Kiota we should still validate:
If any above validation fails, we need throw an error.
For inheritance (allOf, oneOf, anyOf) in request bodies, I've created a new issue for Kiota to handle the scenario: https://github.com/microsoft/kiota/issues/5164
For the circular reference we should list all selected paths that are causing the error. I'm good with moving to Todo @petrhollayms
@sebastienlevert To confirm- OpenAPI version 3.1.0 shall throw an error, given that it is not yet supported in OpenAPI.NET library, right?
Support for 3.1 https://github.com/microsoft/OpenAPI.NET/issues/795 will be released in the upcoming 2.0 version.
Absolutely.
The OpenAPI.NET throws an exception on this
Error shall be shown to the user when using 3.1
Can we have more description for
Circular references in open API spec are not supported
@darrelmiller Do we have any better description or examples? It shall not be too restrictive now, I see some risk in there.
I have no idea what is meant by Circular references are not supported.
I can imagine that if you try to create a plugin with a request payload that has a schema that is self referencing then Semantic Kernel will not be able to call that API. That is probably because SK cannot support nested objects that contain parameters that have the same property names. This is a bug they are planning to fix in the next sprint.
Thanks @darrelmiller , so suggesting we keep it for post-GA and re-evaluate later on based on the feedback from users.
We need to enhance the plugin generation process in Kiota by implementing validation rules. These validations will ensure that the generated plugins function correctly. Some of these validations address current limitations that may be resolved in the future. However, it is crucial to ensure that the generated plugins work with the current constraints.
Requirements