my api resource url: http://apis.juhe.cn/simpleWeather/query?city=θε·&key=
however, i type in base url "http://apis.juhe.cn/simpleWeather/query", it will return
"http://apis.juhe.cn/simpleWeather/query/"
how to delete the '/' at the end of base url,
Hi @myto! As a quick fix, would you be able to use http://apis.juhe.cn/simpleWeather as the Base URL, which will automatically add a slash, so in your resource you'll run the request to http://apis.juhe.cn/simpleWeather/.
Then you can manually add query in before the URL parameters?
Thanks.
It is good idea.
I have the same problem. This slash is a system error, it shouldn't be there. If in the above example the parameter "query" is entered without a value, then it will be included in the string as "query=".
Help me create an API request like this:
https://api.privatbank.ua/p24api/pubinfo?json&exchange&coursid=NUMBER where NUMBER is a user variable
Hey @Artem! Just to double check, are you asking how to allow users to enter the param value?
I'm fascinated by the platform and features, but this is the second time I've run into the same problem that I can't solve with web searches.
Please help me with this example...
I am creating an API request. I receive the answer in which there is a key-value. Next, I create a SQL query to create a table into which to transfer all received key-values. There is a problem at the stage of creating a SQL request. Key values ββin the query itself are displayed in quotes, which cause an error. But if I use the value of this key in a text field, then there are no quotes there.
I've read all the instructions and can't find anything similar. Sometimes quotes or slashes appear where they should not be, and there is no way to remove them. Help me!
Definitely happy to help! Would you mind sharing screenshots of your two queries?
Thank you for sharing those super detailed screenshots! Hmm, for your first question, have you tried disabling prepared statements?
By default, all of our SQL queries are converted to prepared statements to prevent SQL injection, meaning that table/database names and SQL functions aren't able to be defined using a string created dynamically. The main reason we currently convert all statements into prepared statements, is so that users can't enter malicious syntax (like DROP TABLE) into the variable fields.
You can disable this setting in the resource setup, but keep in mind the potential of submitting dangerous SQL through any of the variables referenced in a query. Disabling prepared statements can also break other existing queries. If that's something you'd like to explore, I often recommend setting up another copy of a resource with that setting enabled to help limit the surface area that you have to keep in mind SQL injection for.
