API query invalid in SnapLogic, but valid in Postman

Split out from: 401 Error using Https in API REST GET call

Did you ever solve your issue?

I am experiencing something similar. To answer the question the User-Agent can be anything. Something like SnapLogic/version# replacing the number.

My issue is that when I run it in Postman I get results.
When I run it in SnapLogic the Server is saying that the query is invalid.

To this date nope. i have tried everything from create an SSL rest account and I am still getting the issue. The API works in postman and the browser but not the rest snap. I am out of ideas at this point

I was told to try something like this and it is working.

My rest API requires a query parameter.

http://ServiceURL?query=select * from table where id=1234

I had put in the URL into the Service URL box and then added a query parameter called query.

That did not work.

What does work is this:

https://ServiceURL /services/?query=’ + encodeURIComponent(‘select * from incidents where id < 1000’)

And that entire line went into the ServiceURL.

Seems that they do not fix the encoding in the query parameters.

Set the Service URL to “https://ServiceURL/services” and use the “Query parameters” table to set the query parameters. See the docs for this snap.

That is what I tried but it did not work without adding the encodeURIComponent function on the query.

My endpoint said that there were invalid characters when I did it as the document shows.

I tried putting the encodeURIComponent function into the query parameter but it doesn’t evaluate the function it sends it as text to the endpoint instead.

Do you have the “=“ sign enabled to make it evaluate as an expression and not just plain text?

I get this error:

Could not compile expression: https://serviceurl … (Reason: Encountered extraneous input ‘:’ at line 1:5; expecting={, ‘||’, ‘&&’, ‘^’, ‘==’, ‘!=’, ‘>’, ‘<’, ‘>=’, ‘<=’, ‘+’, ‘-’, ‘*’, ‘/’, ‘%’, ‘?’, ‘instanceof’, ‘in’, ‘matches’, ‘[’, ‘(’, ‘.’, PropertyRef}; Resolution: Please check expression syntax)

Query parameter looks like this:

incase the image doesn’t work:

Query parameter | Query parameter value
query | encodeURIComponent(‘select * from mytable where id < 1000’)

using your expression I am seeing this result:

It is not necessary to use encodeURIComponent. The REST Get snap will properly encode the query parameter values. Can you please show the full configuration of your REST Get snap?

I also have to say that providing a REST service which accepts a SQL command to execute against your database seems like a rather significant security vulnerability.

It is not SQL. It is Oracle’s proprietary language ROQL.

I am not sure how to send you the configuration.

Post a screenshot of the REST Get settings.

Let me clarify what would help us help you. You said you tried making a query with Postman which worked, but you tried making the same query with REST Get which didn’t work. Please post a screenshot of both showing the full configuration.

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”: https://learning.postman.com/docs/developer/echo-api/

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?

Ah that explains it. Unfortunately, I have no control of the receiving endpoint. It is an Oracle Endpoint.

Maybe it could be added as an option to the Rest Get? To be able to encodeURIComponent (encode query parameters).


Yes, we could have an option in Rest Get to control how the query parameters are encoded. Or is the workaround using encodeURIComponent in the Service URL expression sufficient for your needs?

The workaround works for now.