Feature Request: Add API for specifying query parameters

[hesch]

Feature Description

I suggest adding a way to add query parameters to the http API. At the moment we need to construct the query parameter string ourselves in JS with something like this:

const queryParams = {
  param: 'val'
};

const queryString = Objects.entries(queryParams)
  .map(([key, val]) => `${key}=${urlencode(val)}`)
  .join('&');

http.get(`https://example.com/test?${queryString}`);

There is neither a way to specify the query params in the params parameter nor the urlencode function available.

Suggested Solution (optional)

In my opinion it would be pretty easy to add this feature by leveraging the already existing support in req.URL.Query(). The API on JS side would look something like this:

http.get(url, {
  queryParms: {
    param1: 'val',
    param2: 'val',
  },
});

On the go side the implementation would probably look something like this:

query := result.Req.URL.Query()
for _, key := range params.Keys() {
	str := params.Get(key).String()
	query.Add(key, str)
}
result.Req.URL.RawQuery = query.Encode()

Already existing or connected issues / PRs (optional)

No response

[joanlopez]

Hi @hesch,

First of all, thanks for contributing with this feature request, it's always nice to receive input from our lovely users.

As you may know, we're designing and planning the work for a New HTTP API, so we consider the current implementation (available at k6/http) as under maintenance only, so we're only committed to bug fixes. Anyway, I'm going to add the new-http label, so we may consider it as part of the new design.

However, I'm not sure if this actually needed, as we already have a JSLib that provides a similar API as the one you're asking for. Have you seen the url lib? 🤔 You can take a look at it at: https://grafana.com/docs/k6/latest/examples/url-query-parameters/

Do you still think that something like what you suggested is really needed? Or it's enough with the lib?

Thanks!

[hesch]

@joanlopez

Thank you for your feedback! I did not know about either the new HTTP API nor the url lib implementation. Thank you for pointing them out. In that case I would just suggest updating the current http documentation to include examples of the usage. That way it is easier for users to know about the url lib and how to work with it.

Regarding implementation of this for the new http-api, I would say it is a trade off between usability and keeping the implementation on the go side minimal. IMO this feature is so minimal that it might as well be implemented, but maybe this opens the floodgates for more and more features, eventually bloating the API.

BTW is there some timeline for the new HTTP module? Where is the primary discussion taking place? It seems like all the relevant issues are almost a year old at this point.

[joanlopez]

Thank you for your feedback! I did not know about either the new HTTP API nor the url lib implementation. Thank you for pointing them out. In that case I would just suggest updating the current http documentation to include examples of the usage. That way it is easier for users to know about the url lib and how to work with it.

Thanks for the feedback! I'll let know our docs team about, so we'll see what can we do to make it more clear.
So far, I'd recommend you to take a look at our Examples section in docs, it's generally useful to discover this kind of "common" operations that aren't specifically covered by main docs.

BTW is there some timeline for the new HTTP module? Where is the primary discussion taking place? It seems like all the relevant issues are almost a year old at this point.

That's an internal ongoing discussion, so unfortunately I cannot share more details yet (no clear plans yet).
But we'll announce it once we have more concrete plans. Stay tuned!

[joanlopez]

Hey @hesch,

Quick update, as I forgot to share with you this issue, which I think is quite related to your feature request: #991

Do you think would be fair to close yours and keep that one? Or do you see any reason to keep this one as well? I can easily link this one in #991 comments to also keep it into consideration. Wdyt?

Thanks!

[hesch]

Let's close this in favor of the other Issue. It is basically the same issue! Thank you for the support.