Anurag is correct about the URL validation.
Practically, the variables are supposed to be either the path variables or the parameters. They are supposed to have different values in real time for each execution.
The Web Service server address (FQDN or IP) and resource URI are supposed to be fixed for each Rest Service task as other properties of the Rest Service task , e.g. Authentication, username, password, return data schema, etc., are fixed and valid for one server and resource URI.
Even though you may use
http://{test} in request URI, the Rest Task itself would not work if other properties would not work for all possible URIs.
Please refer to the Help on the Rest URI of the Call Rest Service task:
<LI class=li> Rest URI (mandatory) – The URI of the web service that is being invoked.
The path variable or the request parameter is in the curly brackets {}. Its name should contain only alphanumeric characters. For example,
- http://host
ort/your-rest-resources/{pathVar1}/{pathVar2}/...
- http://host
ort/your-rest-resources?param1={requestParam1}¶m2={requestPa ram2}
- http://host
ort/your-rest-resources/ (There is no variable/parameter in the URL. There could be some in the payload.)
For a REST resource URI, for example,
http://www.thomas-bayer.com/sqlrest/...est/CUSTOMER/2 or
http://www.thomas-bayer.com/sqlrest/CUSTOMER/3, replace the exact customer number 1, 2, or 3 with a run-time parameter. Then, fill in the Rest URI value with http://www.thomas-bayer.com/sqlrest/CUSTOMER/{pathVar1}.