I have tried all kinds of permutations and combinations of these settings. Regardless of the settings or if I use the encodeURIComponent(‘select * from mytable where id < 1000’) in the Parameter or the = is checked or unchecked. I get different errors for all of those scenarios. The only thing that works is what I posted first with he encodeURIComponent.
Ok, I know what’s going on. Here’s the pipeline I describe below:
REST param encode_2021_01_29.slp (4.6 KB)
This uses a simple REST API provided by Postman called “echo”: Echo API | Postman Learning Center
The pipeline has two instances of the REST Get snap configured differently:
“REST Get encode” is configured with an expression in the Service URL which uses encodeURIComponent to encode the query parameter value:
“REST Get simple” is configured without using any expressions; it uses the Query Parameters table to pass the query parameter and leaves it out of the Service URL:
Both of these work as expected, but they encode the URL a little differently.
Here’s the output of both snaps. The echo API’s response shows both the “url” it received and how it was decoded under “args”:
Notice that the URL is different: the “REST Get encode” encodes the spaces in the query value as “%20”, while the “REST Get simple” encodes them as “+”. But both of these are valid ways to encode a space in a URL. And you’ll notice that the echo API decodes them the same way; both produce the same resulting “args” value, the same decoded string where both %20 and + are decoded as a space.
The API you are calling is not understanding them the same way. It’s correctly decoding %20 as a space, but it’s not correctly decoding + as a space.
Do you have control over the implementation of the API you’re calling to fix it on the server side so it accepts either valid encoding?
