Missing path parameters

[almamatter9]

Can you add "path parameters" in the Params tab

Thks

[rangav]

Hi @almamatter9 what you mean by path parameters, can you please provider an example?

[almamatter9]

Hi @rangav,

For a endpoint like this :
/orders/{id}/item
{id} is a path parameter

Here down below, how Postman handle both Query Params and path params (or path variable)

In Postman, to use a path parameter, we need to enter the parameter name after a colon :
/orders/:id/item

• when we enter that kind of parameter, Postman will populate it in the Params tab.

[rangav]

ok got it, I will add this to the product roadmap.

[mazoqui]

Hi @rangav. Congrats you for such amazing job!

It seems, query parameters does not render enviroment variables too. I belive issues are related.

[rangav]

Hi @mazoqui thank you. Can you post a screenshot or more details about the query params and env var issue?

[mazoqui]

Hi @rangav - thank you for the quick response.

"Base" and "Output" variables are defined, yet I need to replace {{varname}} with related value to get this request to work

[ZooDoo4U]

Hope i'm not late to the party. Just found Thunder a couple days ago, very nice indeed :) As of now this is the only thing that feels like it lacks and missing, allowing variables in the URI. Just curious for this update does it allow for variables being defined at both the collection level (effectively global for the collection) and/or the individual request level?

Following along with this, and kind of related. Allow the base URI for the collection to be configurable? In postman i would often have my queries to be {{URI}}:{{Port}}. Sure you see why :) The one down side for this is losing the "www.thunderclient.io" reference. Hmmm suggestion two? On the side of the UI, put a "What's new" i.e.:
Response Headers Cookies Test Resuls What's New { }

Anyway thanks for an awesome tool. For me postman just met up with the garbage man and is heading to the dump!

[rangav]

Hi @ZooDoo4U thanks for feedback

you can use environment variables for baseUrl and port and for other parameters

Will soon implement path parameters

[ZooDoo4U]

But using environment variables alone seems problematic? If using 2 or more collection and using what {{#host}}, as soon as one get 2 or more collection which may have different end point, we run into an issue? Environment variables might be a decent stop gap, but not a sustainable solution in the long run. Would assert the variables belong within and should be bound directly in the collection...

[rangav]

Linking a environment with a collection is in roadmap.

will start work on collection level options like headers, auth etc in early July.

[dj-nitehawk]

lack of path variable support and not being able to set auth token at root level (and be able to override in deeper levels) are the only two things preventing me from switching to thunder client.

@rangav hope you'll implement these soon... and keep up the good work!!! awesome stuff!!!

[rangav]

Hi @dj-nitehawk thanks for feedback. planning to start work in july, there are few things todo in my list before i start this.

[transfer76]

Hi guys!
I`ve downloaded latest version 1.6.1 and as I understand path params are not implemented yet?
thanks a lot)

[ZooDoo4U]

Hi @transfer76,

I think it needs a little work, but with the latest version (i'm running 1.5.0, just noticed 1.6 available). Anyway it might be like myself, took a little stumbling to get them working. Where postman will show your param/variables at the same time as your query... You will first need to create an Env. Define your params in the Env, now back to your query collection and define a query such as:

{{baseUrl}}:{{port}}/bible/{{bibleVersion}}/FullBookNames

So from the variables you defined in you Env, just wrap them as show with:

{{yourParamNameGoesHere}}

Think this should get you working. The one thing missing is allowing "Global" params at the "Collection" which may be overridden on an individual query within the collection.

[yuu-eguci]

Cannot wait for the feature, path parameters("path variable" in Postman)!

[nghtstr]

@rangav if I may contribute to the discussion. The use of path variables is extremely helpful when keeping the route the same between code and api testing. So with that in mind, may I suggest that only for path variables, the format for that be :var_name instead of {var_name}? The reason for that is that many of the routing packages (like go-echo) use that format to state a path variable. Also, the transition from Postman to Thunder would be far easier. Lastly, by having that variable in place, the url doesn’t need to change, just the contents of the variable (which I don’t think need to be saved in with the configuration).

Just my two cents, in trying to make a plug-in that is already fantastic, just that much better!!

[rangav]

Hi all, I will include this feature for the next update v1.9.0

see all features planned #282

These variables work in request level only

[ZooDoo4U]

I wouldn't be a fan of using ":var_name" for a parameter. In a URL ':' can be used as a valid legal character making up the URI itself, while "{}" aren't. That would be the first reason not to change what is already being used. Which now means there would also be a breaking change all users with collections now that will need to fixed. And finally, would assert most of us are web developers, be it Javascript itself, React, Angular or any other tool/component we will already use.... Just feels a lot more natural for variable substitution follow the language and frameworks/libraries we all use daily...?

Ah and one last thing with only using ":" where does the parameter name end if only :some_variable::port:domain:component

Just seems using the "{}" is be cleaner and obvious, my example with the port in my example. Is that a valid URI, did i mean for the ':' before the port or not? My point it isn't definitive the author's intention does port === ":80" or "80"? Just saying this is clear and obvious... No? And here there is no ambiguity...
{{host}}{{port}}{{domain}}{request}}

[rangav]

Hi @ZooDoo4U thanks for the feedback, {{variable}} is used for environment variables

for path variable are you suggesting to use single bracket {variable}?

[ZooDoo4U]

@rangav Thanks for your attention, glad you liked the feedback. I'd assert one or two "{}" would be fine. Double checking not sure why i was using two, seems when i was googling how to use the place holders the pages/references i found used two and that is what was working for me. Double checking and searching again, now i'm seeing others are using only one, so using two is more from my confusion... (sorry) I'd assert one "{}" would be perfect, then again most developer might agree 99% of most bugs are one off errors ;) Either way love to see your work and attention to your users....

[nghtstr]

While I understand why people are weirded out by :my_var variant of defining a variable. Like I said before, there are a lot of backend tools out there that make use of the idiom of /path/to/route/:variable. Also, for people jumping the ship that is Postman, this will make the change significantly easier.

Besides, the only time a : is valid is after the top level domain, and before the path.

[ZooDoo4U]

I would humbly reject your assertion the ':' is only valid as mentioned. Found this reference on Quora
https://www.quora.com/Is-it-safe-to-use-a-colon-in-the-path-of-a-URL

In the end it will point you to the RFC 3986 4.2
https://datatracker.ietf.org/doc/html/rfc3986#section-4.2

Also just wrote a sample Rest Api with ASP.NET.

https://localhost:44338/TestApiEndpoint/abc:def

Worked just fine... Okay i'm assuming MS is adhering to the RFC 3986 spec...

But even being a back end only developer for 40+ years, would prefer the "{}", seeing a :var_name would seem more like a target for goto target command/script file, nothing related to web request... Not clear why you are asserting ":this" is more useful or easier?

And carrying on with usefulness, with the "{}" i can directly copy my request into my javascript, use back ticks and fix up my place holder variable names (which if that is what i'm using in Thunder Client, good chance the same was what i have in my JS)??? With this absolutely no fixup required for my copied URI? Not possible with ":this"? And even when i paste the URI into my C# code, use $"" for string interpolation again no fix up. I like the option to have no fix up and copy directly from Thunder Client to my actual code, no fuss, no errors, worked when i tested, should work in either my JS or C# code... And if the thunder client collection could be shared (which i'm assuming could be but not 100% sure) that would help impose a coding style on all :)

Sorry to belabor the point, just haven't heard one reasonable reason for using ":this". Or i'd be curious which language if any would all for string interpolation with:
var url = ?":host:port:domain";

Would simply follow javascript ES5 or ES6... They are the most common for the web these days...?

[rangav]

Hi @ZooDoo4U

@nghtstr is suggesting that using :pathname format makes it easy for users who are migrating from other tools like Postman and Insomnia

there is always pros and cons for using new format

[ZooDoo4U]

@rangav Fair enough, from what i'm seeing Postman nor Insomnia use ":this". Insomnia uses {{this}} Postman {this}. Would like to know which tool actually uses ":this". I'm curious what tool(s) are using ":this" in case i ever come across it so i can be prepared for it :)

[rangav]

Insomnia path params
https://github.com/gschier/insomnia-plugin-path-parameters

postman
https://learning.postman.com/docs/sending-requests/requests/#sending-parameters

Both use :name format for path parameters

don't confuse with environment variables format {{variable}}

[ZooDoo4U]

@rangav While this discussion does open up a question i'm not sure about Sharing collections. Would agree it is a separate issue. Saving and passing around collections between users. At work for Postman we have a collection file we can import/export and it is checked into git (less the actual keys). From what see there is no way to allow for this sharing... Am I missing that, not seeing where or how to do that. Just ask, i'll open a new request.

[rangav]

@ZooDoo4U sharing works in TC, by saving requests in git repository, see below link for Team features
https://github.com/rangav/thunder-client-support#team

[ZooDoo4U]

I'm not familiar with Insomnia, but i know Postman uses "{}" i'm not seeing on their page ":this".

https://learning.postman.com/docs/sending-requests/variables/

While there should be a really compelling reason to not use "{}" given the point you can copy/paste from TC to my actual code....

Cheers :)

[ZooDoo4U]

Awesome, i tend not to check updates for VS Code often. Sure enough installed the newest Bingo.. there it is :)

[rangav]

looks like there is some limitations with format :pathName

Following use-cases might be tricky to do and not possible in other clients

• https://example.com/user-:id/
• https://example.com/:clientId-:secondName/

[ZooDoo4U]

I'm curious when, where, how did ":PathName" become popular, i do lots of web api stuff. Or for that matter seems a lot better to remain simple to have an API like:
http://myApi
http://myApi/Customer
http://myApi/Customer/Id
http://myApi/Customer/Id/Childern
http://myApi/Customer/Id/Childern/Id

Very straight forward, ":pathSegment" is not needed and query params simply help influence things like paging size, sort order, values filters, and the like.... All the while given the HTTP Verb they may all have a body for a payload. I'm just not seeing the need to have ":param".

[rangav]

Hi all,

I think it's better to use different syntax for path params to address these limitations #23 (comment)

so planning to use format {variable} as suggested by @ZooDoo4U

When importing postman collection the extension with convert to this format.

let me know any further feedback

[rangav]

This feature is now implemented in v1.9.0
https://github.com/rangav/thunder-client-support/releases/tag/v1.9.0

please let me know if any feedback

[ZooDoo4U]

Awesome work @rangav, will check it out. Again thanks for your support!!!

[nghtstr]

There is a small bug. And I think this was the reason why I was proposing :variable versus {variable}

The environment variables should not be in the Query Parameters section

[rangav]

Thanks @nghtstr for reporting the bug, will try to fix it asap.

[ZooDoo4U]

If i'm not mistaken, i started off using "{{var}}" as it as the only example if found, you only need "{var}", but then again that might be a nice solution use "{single}" for query params and "{{double}}" for environment... Or if i'm understanding it you have duplicate names for both and you're battling which has precedence? Sorry your bug and issue isn't exactly clear.

[rangav]

yes thats the plan to use "{single}" for query params and "{{double}}" for environment. thats how its implemented now.

But i did not test this use case you mentioned above for bug.

[rangav]

Just now did a quick release v1.9.1 to fix this bug, please test and let me know if its working or not.