Dynamic keys for query params in request template

[arunrajkumar235 (Arun Rajkumar)]

I’m currently building an app on Platform version 2.3 making use of Request Templates.

I have a requirement where I generate the key for Query Params dynamically.
I see that it is supported by the platform from the documentation that was available.

However, there seems to be no option to provide the key for the Query Params at run-time.

In the same document, the example only shows the definition of query inside requests.json.
This does not allow me to dynamically create query param keys.

How can I dynamically create and query params using the request template?

I need to be able to invoke a request template like so:

 window.client.request
        .invokeTemplate('getSomeData', {
          cache: true,
          context: {
            domain,
            token,
          },
          query: {
             page: 3,
             q: "contact",
             sets: "contacts,fields"
          },
        });

However, the query param keys: page, q and sets are not known at app build time. They are obtained only during the app’s run-time.

Please help.

[arunrajkumar235 (Arun Rajkumar)]

@zach_jones_noel , @Asif, bringing it to your notice.

[arunrajkumar235 (Arun Rajkumar)]

As a follow up, I also need the ability to send dynamic keys in the header section of the request template.

Earlier, it was allowed in the request method and is not allowed now.

I can understand not allowing context substitution in header values for security reasons.

But, why prevent dynamic key names for headers and query params?

This prevents me from building generic apps that fetch data from external sources whose host names are configured in the iparams.

[cheld (Chregu)]

Hi Arun

I haven’t tried it, but wouldn’t it work with the following scenario (putting the query into context):

window.client.request
        .invokeTemplate('getSomeData', {
          cache: true,
          context: {
            domain,
            token,
            query: {
              page: 3,
              q: "contact",
              sets: "contacts,fields"
           },
          }          
        });

and then in the request.json use context.query:

    "getSomeData": {
        "schema": {
          "method": "GET",
          "host": "yourhost.com",
          "path": "/yourapi/<%= context.domain %>",
          "headers": {
            "Authorization": "Bearer <%= iparam.api_key %>",
            "Content-Type": "application/json"
          },
          "query": <%= context.query %>
        }
    },

Just as a possible idea

[arunrajkumar235 (Arun Rajkumar)]

Thanks for sharing, @cheld. Unfortunately this doesn’t work. The request template does not accept “query” as a context value. It has to be supported by the framework.

[zach_jones_noel (Jones Zachariah Noel N)]

Hey @arunrajkumar235,

Request Templates is a feature focused to improvise the security involved in making an HTTP API invocation, that said, dynamic parameters would in a sense compromise on able to modify the endpoint URL so we don’t support dynamic parameters.

You can define the templates with parameters such as -

"query": {
       "page": "<%= context.page %>",
       "q": "<%= context.q %>",
       "sets": "<%= context.sets %>",
}

And with context invoking the template -

client.request.invokeTemplate('getSomeData', {
         context: {
             page: 3,
             q: "contact",
             sets: "contacts,fields"
          }
       });

[arunrajkumar235 (Arun Rajkumar)]

Hi @zach_jones_noel ,

My app allows the admin to configure the query params’ key and value.
Hence, I do not know the keys of the query params at compile time.

The query param key and value need to be dynamically substituted at run-time.

I don’t see any harm in allowing key and value pair substitution from iparams, even from a security standpoint.

Here’s what I think should be allowed in query params substitution:

Allow queryParam key substitution through secure/non-secure iparams.
Allow queryParam value substitution through secure/non-secure iparams as well as context.

Regards,
Arun Rajkumar