search

postmanlabs / postman-app-support

Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.
https://www.postman.com
5.81k stars 839 forks source link

Imported Swagger 2.0 YAML uses the wrong path variable syntax #4598

Closed erodewald closed 4 years ago

erodewald commented 6 years ago

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: image

Path definition: image

Param definition: image

What I expect to see: image

App information (please complete the following information):

Additional context None that I am aware of.

Ghusar commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@umeshp7 @arlemi

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

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 image

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 3 years ago

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

digetl commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

@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: https://github.com/postmanlabs/postman-app-support/issues/4598#issuecomment-635804180 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 commented 1 year ago

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

techguydave commented 1 year ago

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 commented 1 year ago

I don't understand why it is closed by :

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

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