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?
