swagger-ui

As one of my good friends pointed out back in 2012, most people don't know how to ask questions[0]. I'm feeling a bit sorry for zahlman in the comment section here, they're doing a good job of defending SO to a comment section that seems to want SO to bend to their own whims, no matter what the stated aims and goals of SO really were. There does seem to be a lot of people in the comments here who wanted SO to be a discussion site, rather than the Q&A site that it was set out to be. I do think it's very unfair of many of you who are claiming SO was hostile or that they unfairly closed questions without bringing the citations required. I'm not saying at all that SO was without it's flaws in leadership, moderators, community or anything else that made the site what it was. But if you're going to complain, at least bring examples, especial

To use a concrete example - Swagger UI 2.0 was plain old html, css, and JS. I was able to easily navigate the code and customize it for my previous company with some extra features we wanted. Swagger UI 3.0+ was completely rewritten in React, and I had a super hard time navigating the new source code and trying to figure out how to achieve the same basic things I did with 2.0 with some minor JS tweaks. I'm sure if I invested a few days/weeks becoming a React expert I would be able to do it. But I wasn't willing to do that, so as a result, we are still on Swagger UI 2.0. Judge for yourself: Swagger UI 2.0: https://github.com/swagger-api/swagger-ui/tree/2.x vs Swagger UI 4.0 https://github.com/swagger-api/swagger-ui

FYI: 'is:issue XSS' : <https://github.com/swagger-api/swagger-ui/issues?q=is%3Aissu...> 'is:open XSS' : <https://github.com/swagger-api/swagger-ui/issues?q=is%3Aopen...>

> stop threatening to remove the normal HTTP API, some of us find that a lot easier to debug I've seen the trend toward complexity in other projects too, and it harms not just ease of debugging, but ease of hacking. Take, for example, Swagger UI[0] v2 was so simple. It was vanilla JS using jQuery. I, as an embedded systems developer, was able to easily hack it so it could read in the OpenAPI JSON from a database and I even added a little search box so you could filter down the APIs you wanted to see. Super fast and easy and worked just the way I wanted it to! Starting with Swagger UI v3, it became... extremely labyrinthine by comparison. It was completely re-written in React JS and now I need a bunch of new tooling to make changes and everything was broken out into dozens of different modular files so I couldn't find where I needed to mak

This is great, but I noticed that the output doesn't fully support OpenAPI 3.0.0, particularly the use of "oneOf" responses. I believe it's because you're calling out to swagger-ui and swagger-ui doesn't support these: https://github.com/swagger-api/swagger-ui/issues/3803 A lot of APIs in the wild actually do utilize oneOf responses (e.g. for returning rich structured errors that have an enum and a human-readable description but which all share the same HTTP status code) -- I know at least at $DAYJOB this was a major deterrent from using OpenAPI.

> Unlike software development, where you can improve things here and there incrementally, with design you need to have an overall view of what you want to do, where you want to get, how the final product should look. There's a downside to this too though. Take swagger-ui[1] for example. A few years ago I installed it at my company. It was great. Then managers wanted more features, so I peaked into the source and found it wasn't too hard to augment the HTML/JS. I added a search bar to filter HTTP APIs by dynamically altering the JSON document. I added a button to generate a PDF. I added a drop down to select release version from a database. It was quick and easy and hackable. Then they got sponsored and redesigned it from the ground up "professionally" using React. I recently tried to upgrade to the latest version and... the level of compl

Have you guys considered switching to swagger-ui (https://github.com/swagger-api/swagger-ui)? This is not to say Google API explorer is bad or swagger-ui is better. Disclosure: I'm top contributor to Swagger Codegen but not Swagger UI.

I assume you've tried Swagger-UI[1] already? We just put out a new version (complete rewrite), you can see it in action here[2]. If you're not a fan, please feel free to open a ticket to give us some feedback. Disclosure: I was contracted to build Swagger-Editor 3.0. [1] https://github.com/swagger-api/swagger-ui [2] http://petstore.swagger.io/

I guess I'll take this opportunity to plug my own little tool for this. I use Swagger [1] and more specifically Swagger UI [2] to generate interactive web-based documentation like the sample at [3]. But rather than relying upon source code annotations to have swagger auto-generate the documentation, or hand-writing swagger's verbose JSON structure, I created a little DSL for it as demonstrated at [4] and available on GitHub at [5]. Let me know if you have any questions about swagger-dsl. It's under-documented right now but perfectly functional. I use it often. [1] http://swagger.io/ [2] https://github.com/swagger-api/swagger-ui [3] http://petstore.swagger.wordnik.com/#!/pet [4] http://intellinote.github.io/swagger-dsl/demo/live.html [5] https://github.com/intellinote/swagger-dsl

I feel like you should give a little shout out to the folks over at Wordnik https://github.com/wordnik/swagger-ui for putting together such an awesome API browser.

Source of that page seems to point to "Swagger UI": https://github.com/wordnik/swagger-ui http://swagger.wordnik.com/

Well done! Know what I think would be really neat? If it could be pointed at an instance of Swagger-UI, or use the same discoverUrl that Swagger-UI would use, and spit out the libraries from that. If you're not familiar.. https://github.com/wordnik/swagger-ui