New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for swagger v3.0.0/OpenAPI #3390

Closed
dancrumb opened this Issue Aug 15, 2017 · 74 comments

Comments

Projects
None yet
@dancrumb

dancrumb commented Aug 15, 2017

App Details:

Postman for Chrome
Version 5.1.3
OS X / x86-64
Chrome 60.0.3112.90

Feature Request

Currently, Swagger import is limited to v1 and v2 of the swagger schema.

With the release of swagger v3.0.0, AKA OpenAPI, is support for this on the roadmap?

@prashantagarwal

This comment has been minimized.

prashantagarwal commented Aug 16, 2017

@dancrumb Thanks. We will review this request and get back to you with an update on this.

@wowi42

This comment has been minimized.

wowi42 commented Sep 25, 2017

Some news?

@OwlLaboratory

This comment has been minimized.

OwlLaboratory commented Nov 9, 2017

It would be very usefull ! :)

@ghost

This comment has been minimized.

ghost commented Nov 17, 2017

We're upgrading stuff to use swagger.core.v3 which gives us OpenApi v3. Support for this in Postman would be very useful!

@DylanC

This comment has been minimized.

DylanC commented Nov 17, 2017

Also interested in this feature. Ready API has supported this feature for some time already.

@rlcomte

This comment has been minimized.

rlcomte commented Nov 24, 2017

As we are using Postman for API testing, and we want to upgrade our Swagger API specs to 3.0, it is a must-have.

@arthurgrig

This comment has been minimized.

arthurgrig commented Nov 30, 2017

This is a must have.

@dvh

This comment has been minimized.

dvh commented Dec 21, 2017

+1

1 similar comment
@lyneca

This comment has been minimized.

lyneca commented Dec 28, 2017

+1

@chadbr

This comment has been minimized.

chadbr commented Jan 5, 2018

any updates here? an ETA?

@a85

This comment has been minimized.

a85 commented Jan 5, 2018

Commented here on our approach towards this: #1669

@Sergi0

This comment has been minimized.

Sergi0 commented Jan 23, 2018

Swagger just announced Swagger Inspector, so openapi 3 support looks like a crucial feature now

@pabloharrys

This comment has been minimized.

pabloharrys commented Jan 26, 2018

+1

@Frank591

This comment has been minimized.

Frank591 commented Jan 31, 2018

Any plans about OpenAPI3 support?

@dmitry-mukhin

This comment has been minimized.

dmitry-mukhin commented Feb 7, 2018

just subscribing to this epic thread :p

@alexmreis

This comment has been minimized.

alexmreis commented Feb 14, 2018

+1

@darkturo

This comment has been minimized.

darkturo commented Feb 27, 2018

Hmm this has been labeled as a feature but I see that is not planned for the next 12 months (https://trello.com/c/4WUkp8Ob/18-track-current-issues-and-log-new-ones-on-github-also-submit-new-feature-requests-here). Actually, it seems it has been lost in the backlog :-/ ...

@ekkinox

This comment has been minimized.

ekkinox commented Mar 8, 2018

+1, with both YAML and JSON support

@sirdawidd

This comment has been minimized.

sirdawidd commented Mar 8, 2018

+1

@realB12

This comment has been minimized.

realB12 commented Mar 12, 2018

I really do not understand why Swagger and now new OpenAPI-Specs have not been considered to be at the base of all the data architecture here. When adding Swagger just as an afterthought I am not convinced to invest into Postman any further because I do not want to be locked into a proprietary product that takes in all the Swagger-stuff but does not give back in return!

@youcef-laribi

This comment has been minimized.

youcef-laribi commented Mar 16, 2018

+1

@zoul

This comment has been minimized.

zoul commented Mar 23, 2018

PLEASE, when you are just adding a +1 comment, do realize you are spamming some twenty people with a useless e-mail. (Just as I am doing now – sorry!) There’s an upvote button on the original post for this precise reason. Use it. ❤️

@itsjavi

This comment has been minimized.

itsjavi commented Apr 14, 2018

@a85 we use Postman at my company with a team license and we use Open API 3.0 too, which is automatically generated from our API. We have in the other hand to maintain Postman manually every time we have new endpoints or changes in our API...

Please understand that being able to import Swagger/Open API (an specification being supported by big companies like Google, Microsoft) is an invaluable and essential resource.

I don't say you have to support the whole specification, but at least being able (in the beginning) to import the basics (path, method, request headers, request body) would be very helpful and incredibly time saving.

If OpenApi/Swagger support is such a problem and has such low priority... we will have to consider to not renew the license anymore.

@a-akimov

This comment has been minimized.

a-akimov commented Jun 1, 2018

Agree with the comments above. Supporting only Swagger 2.0 doesn't help Postman get more traction from those companies who build their API lifecycle around OpenAPI 3.0. And OpenAPI 3.0 is becoming a de-facto standard for defining and describing web APIs.

Please, support OpenAPI 3.0 in Postman.

@a85 a85 added the Plugin label Jun 16, 2018

@dinamic

This comment has been minimized.

dinamic commented Jun 19, 2018

Guys, it's been almost a year since this issue was posted. Should this have been properly handled, you could have had an implementation half a year ago.

Please, raise the priority of this feature request!

@philsturgeon

This comment has been minimized.

philsturgeon commented Jun 20, 2018

Seeing as this process is import only (that's not ideal but lets save that for another place) the import process could very easily be based around swagger2openapi, which will convert OpenAPI v2 to v3.

If you build your code to support v3 only and convert up from v2, you'll have everything covered. Honestly Swagger 1.x is so out of date there's not much supporting it, and if folks need to convert there are other ways to get that done, like APImatic Transformer.

@rdkls

This comment has been minimized.

rdkls commented Nov 15, 2018

I just set up docker image to solve by converting v3 => v2

docker run --rm -v $PWD:/tmp -e OPENAPI_FILE=swagger.yml rdkls/openapi2swagger > swagger.openapiv2.yml

Also includes free bitcoin miner!
(j/k but pls check dockerfiles before running ...)

(thanks juan-lb on github, and LucyBot-Inc/api-spec-converter)

@stellis

This comment has been minimized.

stellis commented Nov 15, 2018

@rdkls Thanks for sharing this, but it's not going to solve the problem for some of us.

v3 has features that can't be converted back down to v2 losslessly. One example is anyOf.

I recently tried a v3-to-Postman converter and the results were a disaster. There were response headers moved into the request parameters, among many other inaccuracies.

There are tons of libraries Postman could use if they wanted to support v3. It's baffling and user-unfriendly that they haven't already.

@a85

This comment has been minimized.

a85 commented Nov 24, 2018

Everyone, We are testing out OpenAPI 3 support in our Canary builds (getpostman.com/canary). It might not be perfect but help us test it out! We are also building a plug-in model that will help us update OpenAPI and schema support independently of releasing a new version of the app. The development of the plug-in system is what has resulted in seemingly no visible progress on this but we see that as an essential part to support OpenAPI and other schema formats in Postman. Eventually, it got pretty taxing for the team to support the variety of importers/exporters in line with our development process.

@philsturgeon

This comment has been minimized.

philsturgeon commented Nov 24, 2018

Amazing! Thank you so much.

Totally understandable that building an entire add on system slowed you down. If a similar situation pops up maybe you could post a link to an issue for “Add-on System” and folks could follow that progress, then folks know what you’re up to and don’t feel like they’re being ignored. :)

I’ll check it out soon. Thanks again!

@luketlancaster

This comment has been minimized.

luketlancaster commented Nov 26, 2018

Just tried the import OpenAPI 3 situation, and it worked really well! Our docs are only so good (and I'm personally only the tiniest bit knowledgeable about all of this 😬), as we're getting things converted over, but it's a great start. Thanks for working on it!

@a85

This comment has been minimized.

a85 commented Nov 26, 2018

@philsturgeon Thanks! I agree with the suggestion. We are getting better at managing the tracker in general but it's hard for to deal with the volume of comments + issues (all great feedback of course). The team will update other threads too. Lots coming up in 2019.

@markmooibroek

This comment has been minimized.

markmooibroek commented Nov 27, 2018

Good to hear this is actively worked on! Tested the function with the Canary build, but got an undefined error. Maybe you can improve things with my json file. Good luck!

open_api_3_test.json.txt

@SamvelRaja

This comment has been minimized.

SamvelRaja commented Nov 27, 2018

@markmooibroek Thanks for providing the Test file.
We could reproduce the issue. We shall update this thread once it gets fixed from our end.

@derrickmehaffy

This comment has been minimized.

derrickmehaffy commented Nov 27, 2018

@SamvelRaja I am also getting an undefined error, I do have a bit of redocs x-data stuff in mine as well, your welcome to use it as a test case also: (Warning it is quite large and it is very possible that it could be user error 😛 ) https://github.com/canonn-science/CAPIv2-Strapi/blob/development/public/openapi.yaml

@SamvelRaja

This comment has been minimized.

SamvelRaja commented Nov 28, 2018

@derrickmehaffy Thanks for providing the test case JSON.

@patthiel

This comment has been minimized.

patthiel commented Nov 28, 2018

@SamvelRaja I experienced the same error as @markmooibroek while attempting to import our OpenAPI 3 spec. In case you need another 10000+ line spec to reproduce from 😄:

https://developers.linode.com/api/v4/openapi.yaml

@abhijitkane

This comment has been minimized.

Member

abhijitkane commented Nov 30, 2018

@patthiel @derrickmehaffy - Your specs should import in the latest version of Postman Canary - 6.6.0-canary02
@markmooibroek - Your spec should import as well. We're tracking an issue where example URLs for requests with path variables in the URL aren't being imported correctly, and we expect a fix to be out in a few days. - postmanlabs/postman-collection#740

@ccs018

This comment has been minimized.

ccs018 commented Nov 30, 2018

6,6,0-canary02 appears to have an issue with forward references. I had a $ref to an element defined later in the file and the import failed with an error that it couldn't find that referenced element. I moved things around so that the element was before the reference and the import succeeded.

I can't post the spec due to proprietary reasons, but if needed I can try to mock something up.

@abhijitkane

This comment has been minimized.

Member

abhijitkane commented Dec 3, 2018

@ccs018 Odd - we look through all components before constructing the requests. An example OAS spec would help.

@ccs018

This comment has been minimized.

ccs018 commented Dec 3, 2018

I'll try to put a sample spec, but might take a couple days before I can do that. Note that this was within the components section - an element in the components $ref'ed to something later within the components.

@abhijitkane

This comment has been minimized.

Member

abhijitkane commented Dec 3, 2018

@ccs018 I'm able to import the JSON at https://gist.github.com/abhijitkane/9ca56ec40bc2668107b85ce92d4f402a with the properly generated response. The Pet schema is referenced in, but defined after Pets.

@Ryandaydev

This comment has been minimized.

Ryandaydev commented Dec 4, 2018

Checked canary build against a working OpenAPI spec, and it imported successfully and requests worked.

@zmes50416

This comment has been minimized.

zmes50416 commented Dec 5, 2018

Tried the canary03 version, import working really well!
But I got one issue that server template variable is not parsing correctly.

According to openAPI 3 document here, It does support server templating.
Can Postman parse it as the Environment variable?
Ex:

server:
  - url: http://{host}:{port}
    variables:
      - host:
      - port:

request should be parsed as http://{{host}}:{{port}}/what/every/your/api
instead it is been parsing as http://{host}:{port}/what/every/your/api

For now I am manually modifying it. It is workable in short term, but an auto parsing when importing will be a lot helpful!

Neverthelast, thank you guys for support OpenAPI, It really help me a lot.

@mm-matthias

This comment has been minimized.

mm-matthias commented Dec 7, 2018

Are OpenAPI files with $refs to other files supported yet? I've got something looking like:

api.yaml:

paths:
  /somepath/:
    get:
      operationId: someoperation
      summary: bla
      responses:
        200:
          description: Successful response
          content:
            application/json:
              schema:
                $ref: 'models.yml#/components/schemas/some-model'

And the models.yml contains the corresponding schema.

When I add api.yaml in Postman's "Import files" section, the importer will complains

Error while importing Open API 3.0: ref models.yml#/components/schemas/some-model not found.

When I try to use the "import folder" option (all my .yml files are in that folder), nothing happens.

Is this scenario supposed to work?

EDIT: Hmm, it does seem to work with a different file that referencs other .yamls. So the message is probably misleading, I guess there is some exception down the line when processing one of the files and this exception is not carried upwards to the message?!

@mm-matthias

This comment has been minimized.

mm-matthias commented Dec 7, 2018

Do you have any plans to add generation/editing of request bodies with OpenAPI 3.0? Having only the urls and query params doesn't really address our needs as all the meat is in the request body.

@philsturgeon

This comment has been minimized.

philsturgeon commented Dec 7, 2018

Entirely agree that request bodies and example requests / responses should be built up using the OpenAPI Schema provided for that request/response.

@allan-walpy allan-walpy referenced this issue Dec 8, 2018

Closed

add ultimate tests and pass them #39

3 of 3 tasks complete
@abhijitkane

This comment has been minimized.

Member

abhijitkane commented Dec 8, 2018

@mm-matthias Could you share a sample spec? Right now, the importer generates a sample request body/example response body based on the schema (for form-data, urlencoded, and raw-JSON formats only). Are you using an XML schema?

@danfowler

This comment has been minimized.

danfowler commented Dec 12, 2018

https://swagger.io/docs/specification/authentication/

After you have defined the security schemes in the securitySchemes section, you can apply them to the whole API or individual operations by adding the security section on the root level or operation level, respectively.

I've defined and applied a security scheme at the root level only, so I would expect each endpoint of the imported collection have an Authorization of type "Inherit auth from parent". Instead, after importing a new collection from my OpenAPI file, each endpoint's Authorization is set to Basic Auth. This is inconvenient, because I then have to manually set each endpoint to inherit its authorization.

I think setting the root level OpenAPI authorization as the Collection authorization (currently, it's "No Auth") and defaulting the endpoint Authorization type to "inherit auth from parent" would be ideal as that is the expected behavior of OpenAPI.

@abhijitkane

This comment has been minimized.

Member

abhijitkane commented Dec 12, 2018

@mm-matthias @philsturgeon We've open-sourced the converter at https://github.com/postmanlabs/openapi-to-postman. The current Postman Canary uses 0.0.7.

We've added basic support for generating XML request/response bodies too - this should show up in the next Canary release.

@danfowler Agreed - will work on this.

@a85

This comment has been minimized.

a85 commented Dec 12, 2018

Thank you for your patience everyone. Closing this issue now. If you have comments/suggestions/bug reports for the feature please file it in the repo that @abhijitkane linked to. We'll be soon rolling out the ability to update plug-ins without having to update the app and improvements to converters will ship much faster.

@a85 a85 closed this Dec 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment