Update to Swagger spec v2

[STRML]

I think we should wait a few weeks on this anyway because there's some instability (like a recent bug in swagger-ui that defaulted all routes to GET regardless of their verb), but eventually we'll want to update loopback-explorer's JSON output to Swagger v2.

[nhagen]

Any update on this?

[bajtos]

@nhagen I am afraid upgrading to 2.0 is not a priority for us at the moment. Can you contribute the upgrade yourself?

[OwenBrotherwood]

Is there a use case for the need for Swagger v2.x?
It is possible for loopback to use a v2.x ie v2 spec to remoting metadata.
It is possible for loopback to present a v1.x so that other software can use the api.
Some common software still have not "upgraded" to use Swagger v2 eg postman so it looks like the priority for v2 is correct....

[bajtos]

It is possible for loopback to use a v2.x ie v2 spec to remoting metadata.

LoopBack uses it's own format for describing remoting metadata. loopback-explorer converts from this custom format to Swagger spec.

I suppose we could support both 1.x and 2.x versions of Swagger spec, either expose each version on a different URL, or provide a configuration option so that the developer calling loopback-explorer can decide which version to use.

[OwenBrotherwood]

Unless someone has a good use case, there doesn't seem any reason to expose 2.x
I was just wondering if there was a good use case.
Until there comes some world dominating piece of software that will only use 2.x, 1.x looks ok.

[nhagen]

I think this might have originally been an issue for me because I wanted to use swagger-js, which IIRC is 2.0 only right now. I don't remember off the top of my head, however.

My view: If loopback is offering Swagger support as a feature that attracts users, those users are going to expect that it will work with other swagger tools. If there is are no plans to support mainline/future Swagger, it should be forked into "Strongloop API Spec". This is especially true if there are no docs specifying how to use the swagger features with other tools. Otherwise I think there's a lot of confusion about what is and isn't compatible with Loopback.

I think all of the core swagger tooling is 2.0 now, so anyone who is coming into the ecosystem is going to be put off if they spend time writing out their spec thinking its useful for many libraries and find out only some of them will consume it.

[raymondfeng]

LoopBack can enhance the endpoint to expose swagger 2.0 spec in addition to 1.2. The spec generator can potentially produce different versions per client request.

It should not be too hard to add the 2.0 support. Contributions are welcome!

[fadeojo]

I think loopback has set a great standard for Nodejs frameworks and swagger 2.0 should be supported. I have tried to convert the swagger 1.2 Api declaration to 2.0 with no success (swagger tools). Please add support for 2.0. I will try and put in my two cents but I'm still learning. Thanks.

[STRML]

FYI, the advert page at strongloop.com says Loopback generates Swagger 2.0 documentation, which is not true.

[Kampfgnom]

👍 Is someone working on this? I will try to find the time to look into it, but that won't be in the next few days or even weeks.

[raymondfeng]

We're starting to look into it.

[sachinhub]

We are trying to publish API generated via loopback onto wso2 publisher. WSO2 publisher version 1.9 can import API from swagger URL. It expects it to be 2.0 specs.

Any update on when we can expect swagger 2.0 spec URL in loopback from timeline perspective?

[bajtos]

FYI: I've just submitted a pull request implementing Swagger Spec 2.0 generator for code review, see #115

[bajtos]

The patch has been landed. I'd like to make few more cleanups and improvements before making a new release. You can npm install strongloop/loopback-explorer to try the new version before it's released to npm.

[OwenBrotherwood]

👍