Skip to content
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

Change the parsing logic which converts OData spec -> Open API to make the * appended to extendible paths configurable #400

Open
dmchughaxway opened this issue Jun 22, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@dmchughaxway
Copy link

Problem description

At the moment, the parser will append a * to any paths to which the api consumer can append additional path parameter. This wildcard appears in the generated open api specification and therefore, will be displayed to consumers in the Marketplace if that API is displayed there. Customer would like a less obtrusive wild card to be used instead.

Feature request

The following (or similar) would be required:

  • Parsing logic should make the wildcard character configurable. We should still allow use of the wildcard for backwards compatibility so perhaps need an environment variable to control that. If populated, use what the environment variable says, otherwise use the * wildcard.
  • For any paths that are extensible (not all of them are), we can include a custom header. Naming of this header should be configurable (see above) and the documentation should list it as optional.
  • OData Routing policy would need to be updated to look for the header in the open API documentation for that route and if found, allow the user to call any path as long as it matches the prefix configured. We will also keep the existing logic with the * wildcard character.

Please Note: I think based on some comments on the OData Routing policy that it may have been envisaged that a route could be configured as follows:
GET /v7/trippin/People*/AddressInfo*
This would provide flexibility in that you could govern such a path without having to statically list all the combinations and permutations of a such a path. Using a header instead would be less flexible.

@dmchughaxway dmchughaxway added the enhancement New feature or request label Jun 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant