Springdoc OpenAPI UI Documentation - swagger-ui

Is it possible to generate swagger ui documentation using interfaces rather than controller classes which implement the those interfaces?
Putting the documentation in the implementation class makes it look cluttered.
Springfox had this option, is it available in springdoc? If so, how to do it?

You just add the OpenAPI annotations on the interface level. An it just works.
This is a sample working demo and the annotation are on the interface level as well:
https://github.com/springdoc/springdoc-openapi-demos/tree/master/springdoc-openapi-spring-boot-2-webmvc

Related

ASP.NET Core Web API : use custom OpenApi specification

I create an API and I would like to use my custom OpenAPI specification for Swagger. Because I go design first. I don't want to generate code from OpenAPI spec; I just want to pass it to Swagger. And I have many separated yml files.
Is it possible?
Thank you
I found it. I have bad set cors... Thanks

How to document RSQL filters in swagger doc?

I looked if there is any out of the box or an extension support, I don't see any. Any reference/approach would be helpful.
There is no out of box support in either Swagger related libraries or Swagger UI for this.
There are couple of options:
Use extension/plugin options provided by Springfox to read your controller metadata and add the supported filter fields to your query parameter description. It supports markdown.
Use vendor extension properties so that it passes supporting information via Swagger YAML/JSON. Then, customize swagger UI to read that information and show some dynamic drop downs in Swagger UI.

Export list of API Paths from OpenAPI spec using swagger ui

I have a bunch of APIs that are documented as OpenAPI v3 specs.
Eg: foo.yaml, bar.yaml and baz.yaml
I also have a Web server that displays the specs in the swagger ui, so all my swagger models are easily consumable by devs, designers and so on.
My question: is there an easy way, using the javascript console, to give me a list of the resource paths?
I've had a quick look around the swagger ui source code but couldn't find anything useful, other than the SwaggerUIBundle object.
The API definition is accessible via ui.specSelectors.specJson(). The value is an Immutable.js Map.
You can use the following code to list all the paths:
let paths = ui.specSelectors.specJson().get("paths")
paths.mapKeys(key => console.log(key))

Programmatically append Swagger operations to generated JSON

I have a Dropwizard application with Swagger annotated Java resource classes. I'm also creating programatic REST resources which, of course, don't end up in the generated Swagger JSON. Is it possible to programmatically add operations via the Java Swagger API such that they end up in the generated JSON along with the annotated resources?
I tried using DefaultJaxrsApiReader.appendOperation but it had no effect.
I'm using com.wordnik:swagger-jaxrs_2.10:1.3.12
EDIT
I ended up just writing a Servlet filter to update the Swagger JSON response. It would be great to get #fehguy's suggestions working somehow. I think that swagger-jaxrs_2.10:1.3.12 isn't new enough to support those POJOs.
as of swagger-core-1.5.1-M1, you can build a swagger POJO which simply needs to be returned by your web application. That means, you can programmatically create the Swagger object and serve it up as JSON from your web service.
For examples of how to build a swagger pojo you can look at the source or an example (test) of building one.
You can also mutate the generated swagger object in your application. That means you can dynamically generate / modify swagger at runtime. There is an example in the swagger-codegen project, where the online code generator (swagger-generator) will detect what languages are enabled in the code generation logic via SPI, and update the swagger spec accordingly with the options:
https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-generator/src/main/java/com/wordnik/swagger/generator/DynamicSwaggerConfig.java

Where do all methods, attributes get wired into grails controller?

I'm looking at grails (2.2), and it's all beautiful and even magical, how it all works. I'm looking at a Controller class which is created with grails create-controller and out of the box it has many methods and properties available, like render(), redirect(), params, request and I presume it goes on and on.
where does all this get wired in? Where in the code/project/framework do I see that render() is made available as a method? And how is it implemented?
As a java developer I'm used to inheritance and code injection and reflection. And in javascript prototypes can do some black magic. But the XXController.groovy is just a standalone object. Is it the name (XXController) or the location (grails-app/controllers?) or is there some injection happening which the IDE can pick up?
Welcome to the wonderfull world of Grails,
Here you have a couple of links that may help you:
The Section of Controllers in the Web Layer docs.
And the docs of the render method. Check it out the "Quick reference" column at the right for more methods avaliable at the Controllers.
If you are wondering how that magic is done, Grails is an open source project, so as usual, go and serve yourself at Github (warning, it is quite large project).
Grails works on the top of Groovy, which is a Dynamic Language with a powerful support of meta programming. Tha is basically the trick of all the magic of Grails
Finally, Grails is a framework based on CoC (Convection over configuration), So the Controllers will be any class under the directory "grails-app/controllers" and with the suffix "Controller". (In the folder of controllers may be "commandObjects as well).
The integration with well-know ides is quite powerful as well, you should check it out
EDIT
You may also found how the render methods behaves here at github.
And more inyected stuff at the Controllers metaClass package
As of Grails 2.0+ it's implemented using an AST transformation - previously it was done by adding the methods to the Groovy MetaClass. The benefits of the new approach are that things will be a bit faster and use less memory.
GORM domain class methods now use this approach too (except for dynamic methods like findByFooAndBar which have to be added dynamically to the metaclass) and those have the benefit of being callable from Java since the AST adds the methods to the bytecode. This doesn't help controllers though since they're only called from Grails itself as the result of a web request.
For the gory details, ControllersApi is where the methods are, and they're mixed into each controller class by a combination of ControllerTransformer and the code in the doWithDynamicMethods closure in ControllersGrailsPlugin

Resources