URL segment parameters

[datashaman]

Rails routing and pretty much most other REST-based systems use segments in the URL to convey context and parameters to the controller. It does not appear possible to do this using POSTMan, which cuts out a large portion of your core users.

[a85]

@datashaman Can you give an example how Postman can help there? Are you talking about Rails controllers? Segments in the URL can be interpreted to be anything by the host system. Postman can not know in advance about the backend system running behind the API.

[datashaman]

I'm suggesting that there be another mode of parameter entry, which matches URL segments. For example, entering the URL:

/accounts/:id

would automatically create a separate entry list for URL parameters (much the same as query params), with the key being id (filled in from the URL pattern above) and the value being entered by the user.

This would allow saving and reusing requests with REST URL segments. This is also backend agnostic, but it's a backend pattern which is used by all REST-based systems.

[a85]

Ok. Makes sense now. Let me think of a way to integrate this into the Postman request sending flow.

[mbuchetics]

+1, this would be great!

[aswinnair]

+1, very essential to the work I am doing too.

[dexcell]

+1 for this feature since this is pretty much needed for many REST API.

Thank you

Some thought to solve this.
Right now we have 'URL Params' and 'Headers' button.
We need to have another one button, probably called 'URL Segments' which behave just like the other two buttons (shows url segment keys).

Image illustration
http://i.imgur.com/xIVIJ.png?1

[xamado]

+1 to this. sorry for making a duplicate ticket.

What I suggested was to make the syntax similar to environment variables, using {{ }} in the url, that way the syntax is similar and postman would mix the environment variables + request specific variables into the url solving.

for example:

http://{{HOST}}/api/v1/users/{{USER}}

HOST would be environment, USER would be request specific.

Anyway, I would be happy with any implementation of this :P

[Catincan]

A new pledge is available on this issue: https://www.catincan.com/bounty/https-github-com-a85-postman-chrome-extension-issues-85 .

[a85]

Update: Started work on this finally.

[a85]

Added to dev-v2 branch. Will be available in v0.9.4!

[thobiaskarlsson]

I'm currently on v0.9.5, but still can't find the support for this amazing feature...? Am I missing something? Great app btw!!!

[a85]

@thobiaskarlsson Just use paths prefixed with a colon. On opening URL params, additional params will show up. I need to make this more apparent though.

[thobiaskarlsson]

Thanks, it works like a charm. One thing though, it would be much better if you could default to an environment/global property if not set in "request scope".
Like: http://hi.com/users/{{userId}}/addresses/{{addressId}}. Here you could be able to specify "userId" either as env/global property OR for this specific request, i.e. fallback to env/global if not set on request.

Optional implementation:
http://hi.com/users/:userId/addressess/:addressId where you could specify e.g. "{{globalUserId}}" as value for the path param. This one would probably be the easier way out due to backward compatibility.

[pdelre]

I'm unable to get this feature to work in the Packaged App v0.9.9.7. It would be the key feature for collections for me.

[a85]

@pdelre An update has been pushed on the Web Store with the fix. The version number should be v0.9.9.9

[datashaman]

Unifying the way segments and environment variables work would make sense.
Same template format.
On 12 Jun 2014 11:32, "Abhinav Asthana" notifications@github.com wrote:

@pdelre https://github.com/pdelre An update has been pushed on the Web
Store with the fix. The version number should be v0.9.9.9

—
Reply to this email directly or view it on GitHub
#85 (comment)
.

[pdelre]

@a85 Thanks. I see how it added the URL Param, but it doesn't seem to be doing the string replacement in either Send or Preview.

[RossValler]

I can confirm this issue is happening in 0.9.9.9

[ericingram]

@a85 Is there any way to disable this feature? We built an API that uses colon characters at the beginning of a segment to access resource metadata. For example GET /:models. Postman replaces ":models" with empty string in this case.

Would you consider passing the original string if no param value is provided to replace it?

[czardoz]

@ericingram, as a workaround, have you tried setting the variable value to ":whatever"?

[datashaman]

I would suggest the easiest approach around this is to rather pass through
the original token if there is no parameter for that URL segment.

So in your case, if there's nothing to substitute for :models, then it
stays as literally :models.

In other cases, where a parameter exists, use the parameter.

On 25 August 2015 at 15:18, Eric notifications@github.com wrote:

@a85 https://github.com/a85 Is there any way to disable this feature?
We built an API that uses colon characters at the beginning of a segment to
access resource metadata. For example GET /:models. Postman replaces
":models" with empty string in this case.

Would you consider passing the original string if no param value is
provided to replace it?

—
Reply to this email directly or view it on GitHub
#85 (comment)
.

[czardoz]

@datashaman, what if someone actually wants to leave that value blank?

The way I see it, ":anything" is a variable. If you want the value to be ":anything", it's best to set it explicitly.

[datashaman]

The problem is there's no way to escape that ':' so it is not recognized as
a placeholder. Add a way to escape the : and also to escape the escape
character and you should be good to go. :)

On 27 August 2015 at 19:45, Aniket Panse notifications@github.com wrote:

@datashaman https://github.com/datashaman, what if someone actually
wants to leave that value blank?

The way I see it, ":anything" is a variable. If you want the value to be
":anything", it's best to set it explicitly.

—
Reply to this email directly or view it on GitHub
#85 (comment)
.

[czardoz]

Not sure what you mean by "there's no way to escape that ':' so it is not recognized as a placeholder".

I was able to send a request to "/:var" with this setup:

This is my server code:

from flask import Flask
app = Flask(__name__)

@app.route('/:var')
def hello_world():
    return 'Hello World!'

if __name__ == '__main__':
    app.run()

and this is the output, which shows that the request was caught on the "/:var" path.

(issue-85)aniket [~/tmp/issue-85] -> python server.py
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
127.0.0.1 - - [28/Aug/2015 14:12:47] "GET /:var HTTP/1.1" 200 -

What escaping functionality is needed here?

[datashaman]

Uh, my bad. I'm misunderstanding the problem. It's not one of escaping, it's of selective replacement of the parameter, but as you've said what if it should be blank. Perhaps a special 'blank' token? But then you need a way to escape that because the 'blank token' might ALSO be a legit parameter in some weird situation. Token-ception. :)

[pvsune]

i'm doing a pre-request script and i noticed that request.url did not change the path variable to correct one (e.g. http://klapaucius.io/:id). do you guys have any idea how i can get the correct url? thanks!

[abhijitkane]

@pvsune The pre-request script does not have variables resolved. You can try changing the :id to {{id}}, and using id as an environment variable.

You can then use a little regex to replace the variable yourself -

var resolvedUrl = request.url.replace(/{{(\w*)}}/g,function(str,key) {return environment[key]});

[pvsune]

thanks @abhijitkane i thought there's a prettier way

[igorsantos07]

I've been wanting this feature for ages <3
However, I had to dig through Google to find it. Is there any place where it's explicitly shown to new users that I've missed?

[gchiacchio]

@pvsune The pre-request script does not have variables resolved.

@abhijitkane Do you think in the future there will be a way to access the path variables as the environment variables from the pre-request scripts?

[cdtinney]

+1.

Would be very useful.

[vcmJonasTarnowetzki]

Can we modify the search pattern to not require a leading slash? My company is working with an api specification that requires url segments with parameters be formatted as /resource=id/. Postman is capable of generating correctly formatted api tests from our swagger.json (ie /resource=:id/) but it cannot identify the parameter :id.

EDIT: It would be better to make the pattern accept either leading slashes or equals symbols ([\/|=]). Otherwise it would accept invalid patterns such as resource:id.