Imported Swagger 2.0 YAML uses the wrong path variable syntax

[erodewald]

Describe the bug
When importing a swagger 2.0 spec in YAML format, the path variables are using the :variable syntax instead of {{variable}}, preventing them from being parsed as variables by the Postman client.

To Reproduce
Steps to reproduce the behavior:

1. Use swagger 2.0 yaml spec
2. Click Import
3. Select yaml file
4. Import successfully
5. View request with path variable, see incorrect variable syntax.
6. View request with query param, see correct variable syntax

Expected behavior
Path variables should use correct {{variable}} syntax, just like query param variables.

Screenshots
Import looks like this:

Path definition:

Param definition:

What I expect to see:

App information (please complete the following information):

• native mac app
• Postman Version 6.0.10
• macOS High Sierra 10.13.4

Additional context
None that I am aware of.

[Ghusar]

Hi @erodewald,

The current postman importers transform the path variables in the colon (:) based syntax and do not convert the path variables into native postman variables.

We are currently working on revamping the suite of the postman importers where we will include better usage of the native postman variables when a specification is imported.

[josiahpeters]

Any further progress on this? I recently tried to import our company's Swagger 2.0 spec into postman and every request requires significant massaging. This would be very useful to have working correctly.

[cjlotz]

Also would like to enquire around further progress. Not being able to import a valid swagger 2.0/openapi 3.0 spec using path variables is a huge productivity killer. It basically renders Postman useless for us as it takes significant effort to manually edit every request to fix these anomalies.

[ggutenberg]

Quick little workaround:

1. Import your Swagger YAML to Postman
2. Export your Postman collection to JSON
3. Run the following:

   sed -E 's/:([a-zA-Z0-9_]+)/{{\1}}/g;' exported_collection.json > fixed_collection.json

4. Import your new collection

[cvgaviao]

I think the issue that I'm dealing with is related to this. If is not let me know and I'll open another one.
After I have imported an openApi file containing a server item like this:

servers:
 url: '{protocol}://{subDomain}.{domain}:{port}/{version}' 

only the first variable is being converted to {{protocol}} all other was kept as is.

[natepappenhagen]

@arlemi

Most recent release 7.22.1 does not seem to fix this bug for me.

Can anyone confirm that their path variables are resolving correctly on swagger/openAPI import? I still just get the baseUrl variable and the rest are notated by :pathVariable

[umeshp7]

The path variables from swagger schema are converted to path variables in postman. Anything with a /:variable syntax is usable as a path variable in postman. We only use this syntax for the ones which are a part of the URL segment. for eg. {{baseurl}}/:pet/:petId.
These :pet and :petId are available for you as path variables at the request level. This was done in such a way because path variables will usually have context for a particular path/request only.

For the ones that are not part of a URL segment we create collection variables with {{}} for them. For example: taking e.g. given by @cvgaviao {protocol}://{subDomain}.{domain}:{port}/{version} => {{protocol}}://{{subDomain}}.{{domain}}:{{port}}/:version.

@natepappenhagen @erodewald @cjlotz I would like to know more how are the path variables in Swagger and OpenAPI are used, so that we can decide the changes accordingly.

[QA-automation-engineer]

@arlemi

Most recent release 7.22.1 does not seem to fix this bug for me.

Can anyone confirm that their path variables are resolving correctly on swagger/openAPI import? I still just get the baseUrl variable and the rest are notated by :pathVariable

I still have this issue on Postman 7.25.0

[arlemi]

@QA-automation-engineer See the post above. Can you please give examples of how you're using path variables and how they are resolved for you? This will help us understand in which case this doesn't work and let us reproduce the issue if possible.

[natepappenhagen]

@umeshp7 @arlemi

What I want the import to look like from swagger -> postman

Maybe it's a lot to ask to fit everyone's needs, but, for me I would like the option to turn all variables into "collection" variables, even the path variables.

What I actually get on import

So I end up with a URL like this. Which technically is OK, but makes it so to import a whole service from swagger to postman I have to manually fill out each param on each request, and when the API changes and I have to import it again and re-fill each individual request's param variables... where if they were just collection variables I could plug and play.

So, an option on import to turn all variables into "collection variables" would be a huge benefit to me and my team's process of not having to manually update our postman collection but have swagger be the source of truth.

[marknotfound]

Hi all, I really appreciate the great work on Postman.

Totally agree w/ @natepappenhagen's last comment that having these path variables as collection variables ({{}} style syntax) would help immensely. For my team it would help us better automate collection runs and monitoring by setting path variables programatically rather than utilizing a fixed set of data.

[Lacni135]

I don't think that having every variable be collection variable is a good idea since having something like a userId is request (path) specific and not specific the collection as a whole.

I think that having the userId be different for different request/path is important for some monitoring/testing scenario.

[natepappenhagen]

@Lacni135
I can't imagine there is a monolithic format that would fit everyone's use cases. I'm simply requesting an 'option' on import to have all variables from swagger into collection variables, if you didn't want that, then you can keep the variables at the request level.

[lukyer]

same problem here, what is actually ":parameter" syntax for? Does it have some semantics? Or is is just for immediate manual variables replace?

[digetl]

I'm still seeing this issue but with JSON:

Imported Swagger JSON uses the wrong path variable syntax

Imported:
"/api/v1/accounts/{globalUserId}/details"

Expected:
"/api/v1/accounts/{{globalUserId}}/details"

Actual:
"/api/v1/accounts/:globalUserId/details"

Postman Mac App v 7.36.1 and Postman web via Mac Chrome

[aishanibhalla]

Seeing the same import issue with swagger.json, is there a fix for this yet?

Imported
"/api/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/v2"

Expected
"/api/subscriptions/{{subscriptionId}}/resourceGroups/{{resourceGroupName}}/v2"

Actual:
"/api/subscriptions/:subscriptionId/resourceGroups/:resourceGroupName/v2"

Postman for Windows
Version 9.14.13
UI Version 9.14.13-ui-220310-0130
Desktop Platform Version 9.14.0
Architecture x64
OS Platform win32 10.0.22000

[umeshp7]

@natepappenhagen Thanks for the suggestion for an "option" for this. Seems like that would be the way to go about this, as the way path params/variables are used in postman is different for every user.

Here is an earlier comment explaining our rationale behind this: #4598 (comment)
We will be digging deep into this and see if there is a solution for this which satisfies both use-cases, else providing an option would be a good middle ground.

[thefuga]

Sorry to bump this, but is there any news on @natepappenhagen suggestion?
Thank you ❤️

[techguydave]

Any updates on this? When I'm testing locally I may want to only test with a specific user for all of my routes.

Example:

                      this would be variable during my testing
                          vvvvvvvvvv
/users/:user_id/profiles/:profile_id
        ^^^^^^^
this would be static for my testing

Ideally on import Postman would see all of the path variables in the spec (at least on import, even better dynamically later) then allow me to choose whether each segment should be a collection variable or not.

[douph1]

I don't understand why it is closed by :

@arlemi arlemi mentioned this issue on Apr 8, 2020
#8296
Merged
@arlemi arlemi closed this as completed in https://github.com/postmanlabs/postman-app-support/pull/8296[on Apr 9, 2020](#4598 (comment))

because changelog in 7.22 https://github.com/postmanlabs/postman-app-support/pull/8296/files
point to #133 wich as nothing in common with this issue

• Fixed an issue where some types of path variables from OpenAPI schemas weren’t imported correctly
  #133.
  search requests in collections...

I think it was closed by mistake