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

Allow GET POST PUT parameter resolution through configuration #99

Open
davidradl opened this issue May 20, 2024 · 2 comments
Open

Allow GET POST PUT parameter resolution through configuration #99

davidradl opened this issue May 20, 2024 · 2 comments

Comments

@davidradl
Copy link
Contributor

davidradl commented May 20, 2024

Currently the code has logic if GET then use query params otherwise use body content to resolve the parameters.

We have recently included 2 prs that allow GETs with body parameters
#87
and path parameters
#79

The fixes involved introducing classes that could be overridden to provide this functionality.

It would make more sense to me to allow configuration to target how parameters are resolved on a per lookup join basis so the main cases could be identified using config not requiring code to be added.

Without the new connector configuration is would default to the existing behaviour. There is an option to say useV2Parameterization, with would honour a new body parameter option than could supply the body parameter, we supply a string of json in a separate connector config (parameterised) option rather than mapping query params to a json body.

So 2 new configuration parameters:

  • useV2Parameterization
  • requestBody - e.g. serialised json that could contain ${} named parameters.

I am hoping we can cover all basic operations with json through configuration. Customization would still be allowed for other cases.

@davidradl
Copy link
Contributor Author

@kristoffSC WDYT?

@davidradl
Copy link
Contributor Author

I am working on this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant