-
Notifications
You must be signed in to change notification settings - Fork 159
Specifying Query Parameters for call: HTTP #910
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
Comments
@matthias-pichler-warrify you can also use top level args with As for uri encoding, I always assumed that was the responsibility of runtimes. |
I only saw |
In principle I am with you on this one but I am thinking of a case where the query parameter keys would also need encoding (e.g. I am also wondering how to elegantly handle array valued query params as there are different representations:
Which could be handled with an appropriate field |
@matthias-pichler-warrify fair enough, you make a very good point! What about using On another note, I believe it would be awesome if the PR addressing the present issue would include documenting the ease of use feature I described in my last comment. Wdyt? |
yeah the top level interpolation caught me by surprise when I first saw it 😅 Questions here:
|
In Synapse, if an expression fails to evaluate, we simply leave it as is. I'm however personally open to any and all suggestions!
That's a very good and very subtle question. I would probably tend to say no, as if need be, one could always use the expression language interpolation feature if complex operations are required. I'm sure it would however be a great quality of life improvement, so we should probably restrict that feature to variable access, no matter the depth.
My take is that only primitive types should be allowed. In Synapse, we transform the result of the evaluation to a string, no matter the original type, so using complex objects or array would produce their string equivalency (which in .NET would be something like |
Uh oh!
There was an error while loading. Please reload this page.
What would you like to be added:
Would it make sense to add a structured way to add query parameters to uris when using
call: http
?We could use the name "search", "query", "searchParameters", "queryparameters" or "parameters"
Why is this needed:
right now it is somewhat painful to specify these things using a runtime expression because we'd need to use the
@uri
format. And@uri
also only encodes interpolated strings so the keys would have to manually encodedThe text was updated successfully, but these errors were encountered: