Add openapi multiple examples

[anukuljha]

No description provided.

[AndrewWalsh]

Hey @anukuljha, appreciate you closed this but here's a heads up on how examples work. They already exist via the mostRecent type https://github.com/AndrewWalsh/openapi-devtools/blob/main/src/utils/types.ts#L58.

This type is unknown. If you wanted to include multiple examples, then it would be best to simply change this to unknown[]. There is no need for a new Example type. Appreciate the code and architecture is not documented.

The implementation is pretty straightforward beyond this. If users enable the feature, then the option enableMoreInfo becomes true, and is included in the MediaTypeObject https://github.com/AndrewWalsh/openapi-devtools/blob/main/src/lib/endpoints-to-oai31.helpers.ts#L97.

An issue with this approach is that the data structure will become very large, and the size becomes unbounded. This could compromise speed, and would affect the import/export feature. Would you be open to raising an issue before raising a PR regarding this matter?

[anukuljha]

Hey @anukuljha, appreciate you closed this but here's a heads up on how examples work. They already exist via the mostRecent type https://github.com/AndrewWalsh/openapi-devtools/blob/main/src/utils/types.ts#L58.

This type is unknown. If you wanted to include multiple examples, then it would be best to simply change this to unknown[]. There is no need for a new Example type. Appreciate the code and architecture is not documented.

The implementation is pretty straightforward beyond this. If users enable the feature, then the option enableMoreInfo becomes true, and is included in the MediaTypeObject https://github.com/AndrewWalsh/openapi-devtools/blob/main/src/lib/endpoints-to-oai31.helpers.ts#L97.

An issue with this approach is that the data structure will become very large, and the size becomes unbounded. This could compromise speed, and would affect the import/export feature. Would you be open to raising an issue before raising a PR regarding this matter?

@AndrewWalsh Hey thanks for replying.
I accidentally raised PR on main repo instead of my forked version. I am working on developing some ways to detect ENUM fields based on all recorded samples during the session, hence I have tried to modify the leaf to store all examples of request/response for the given path.
It is still a work in progress and I didn't mean to raise the PR on main repo yet. When I am able to build something usable on this, will surely raise PR when it's ready.

[AndrewWalsh]

Ok cool, sounds interesting. Server based tools like Akita can achieve this because they receive tens or hundreds of thousands of requests. They have enough data to sift through and determine patterns such as fields that are enums. This tool doesn't have that advantage as it is only aware of requests that the client has triggered. It doesn't have anywhere near that much data, and works on the assumption that an endpoint may be defined by only a single request. Collecting samples en masse would be problematic and wouldn't suit this tool, but an alternative data structure might work. Just a friendly heads up, as data validation is very difficult to determine in the context this tool works with given a very limited set of data.