Query values inconsistently percent-encoded

[Roy-Orbison]

Reproducible via the following example:

The resulting URL is https://rester.example/api/?a=x%2By&b=x+y. It looks like variable substitutions are done in an unintuitive order. One has to put a literal %2B into the variable value to work around this.

[frigus02]

Thanks for the report. Yeah, variable substitution is a bit inconsistent at the moment. I believe it doesn't happen at all for the URL. This is to allow variables for the URL part, e.g. url = http://my-dev-environment:8000. But this isn't a good fit for query parameters.

I will need to think about how to approach this. Is there a way to make this intuitive for most users?

[Roy-Orbison]

I think one of the issues is that collapsing the above example makes the URL become https://rester.example/api/?a=x%2By&b={b} rather than https://rester.example/api/?a=x%2By&b=%7Bb%7D. Variables' contexts are lost on expand/collapse.

What if one could specify encoding? E.g. {foo|base64} and {foo|urlencode} would both refer to the same variable foo, but change how it's rendered. Then you could make the default encoding for URL variables to raw, but the query keys' and values' urlencode. A mock-up of the idea:

This would also be great for strings in JSON (omitting surrounding quotes from the encoded output to allow placement within strings), e.g.:

{
	"foo": "{bar|json}",
	"baz": "I can't believe it's not {qux|json}!"
}

I used a pipe as the separator of variable name and transformation because it is a convention in use by several template engines that also employ braces.