Support for query parameters

[Leon99]

Applicability of this tool would be so much higher if it supported listing and specifying query parameters.

[tlmii]

I agree - definitely something I want to look into. Thanks for flagging it.

[salihkarabilo]

Could you prioritize this ? As I think the most common case to use Httprepl is when running a simple get request with some query string values.

[bravecobra]

Without query parameter support, this tool is unusable for us. We use FromQuery all the time in our api's

[bradygaster]

@tlmii this feels like something that we'll need to prioritize in the next iteration. What say you?

[tlmii]

@bradygaster I'm definitely fine with prioritizing it. We just have lots of questions to answer before we can put more code down (other than #448).

We have the information from the OpenAPI Description to say what the available query string parameters are for a given endpoint. So that's helpful. But what we need to figure out is how does the user specify them?

• Is there a corollary to the cd way of drilling in through the path parameters that we could use with query string parameters?
• Is it just an option on the various HTTP commands (effectively the per-call equivalent of the global command in #448)?
• Do we display it as part of the prompt?
• Should we display them as part of the results of an ls?

I'd be curious to know from the others in this thread (@bravecobra @salihkarabilo @Leon99 ) what their use cases are from the three scenarios I outlined in https://github.com/dotnet/HttpRepl/pull/448#issuecomment-735010282. An interesting data point to glean from folks is just how often they're using per-call query string parameters vs global.

[bravecobra]

To clarify my particular use-case here: I want to use the HttpRepl for scripting out user-scenarios for integration testing, a series of api calls to be executed so to say. Something like,

• add a product
• get the product
• update the product description
• search for a partial description and verify the product is found
• update the product price
• get the product again and verify the price has been updated.

Since our api's use query parameters, that was a no-go up until now. Currently I'm looking into an efficient way to do this, either use the HttpRepl and script it out, or use PostMan or setup a C# unittest with a generated C# client from the openapi spec. I have to rule out the HttpRepl for now.

Note that query parameters are not always required, listing them out as part of the ls command would require listing out every possible combination when multiple query parameters are involved. I'd imagine it would be handy to list out all the available ones when describing one particular route, but not on a list of routes. In other words, I don't use the httprepl as an api-browser, but I want to be able to make any call the api exposes. Hope this helps.

[bradygaster]

@bravecobra this scenario is exactly like the one we ask customers to complete who gave us feedback on the tool (you're welcome to sign up, too, if interested ping me), so your walk-through summary is awesome. Up to now we've specifically [and for obvious reasons] targeted a sample API that makes use of route-inclusive variables rather than [FromQuery]-obtained variables. I think updating that sample such that it'd include some use-cases of [FromQuery] APIs, and then use that sample repository as maybe a use-case of all the things we'd want to enable for the HttpRepl.

[andrerav]

I'm a big fan of this tool and use it on a regular basis. I was flustered to see that it doesn't support specifying query string parameters. I see that you have a PR ready for this, so I hope it will be resolved soon :)

[mikoskinen]

Any updates on this? Like others have mentioned, it's hard to use httprepl with many of the APIs because of the lack of support for query parameters.

Thank you in advance for the updates.

[bradygaster]

We haven't triaged here in some time - I'll circle some folks together and we'll triage and update the community on this.