The OpenAPI specification itself is unrelated to MicroProfile. It’s a specification designed to provide a standard format for documenting REST API services. An OpenAPI document looks similar to the following:
 
openapi: "3.0.0"
info:
  version: 1.0.0
  title: Swagger Document
servers:
  - url: http://test.payara.fish/v1
paths:
  /hello:
    get:
      summary: "Returns a hello world message."
      operationId: helloWorld
      parameters:
        - name: count
          in: query
          description: "How many instances of the message to return."
          required: false
          schema:
            type: integer
      responses:
        200:
          description: "A hello world message."
          content:
            text/plain:
              schema:
                type: string
        500:
          description: "An unexpected error."
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
components:
  schemas:
    Error:
      required:
        - code
        - message
      properties:
        code:
          type: integer
        message:
          type: string
 
 
 
 
 
This document contains things such as:
- a list of common objects
- a list of servers the API is available from
- a list of each path in the API as well as what parameters it accepts
This document is extremely useful since, as it follows a standard, it can be used in a range of tools such as those provided by the Swagger suite. These let you do all sorts of things such as design, edit and test a REST API documented by an OpenAPI document.
 
MicroProfile designed the MicroProfile OpenAPI specification to extend the general OpenAPI specification and integrate it into MicroProfile applications. specification states that any implementing servers should host an endpoint at /openapi which will provide an OpenAPI document built from a deployed application. When you deploy an application, this document will be built automatically according to the application contents. The document can then be edited or used however you like. The specification also illustrates a few methods of editing this document. You could for example add a description to an endpoint, or a new title for the document so that the document hosted at the /openapi endpoint appears in any way you like.
 
No configuration is needed for the OpenAPI implementation in the Payara Platform, you need just deploy an application! The OpenAPI is included in Payara Micro and Payara Server, so which one you use doesn’t matter. For a full example of the usage, see the specification documentation.
 
Let’s say you deployed an application with only the following classes:
 
import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;
 
@ApplicationPath("/api")
public class TestApplication extends Application {
}
 
 
 
 
 
import javax.ws.rs.Path;
import javax.ws.rs.GET;
 
@Path("/hello")
public class TracedResource {
 
    @GET
    public String helloWorld() {
        return "Hello World!";
    }
}
 
 
 
 
With this application deployed, visiting http://localhost:8080/openapi/ will produce the following document:
 
openapi: 3.0.0
info:
  title: Deployed Resources
  version: 1.0.0
servers:
- url: http://localhost:8080/app
  description: Default Server.
paths:
  /api/hello:
    get:
      operationId: helloWorld
      responses:
        default:
          description: Default Response.
          content:
            '*/*':
              schema:
                type: string
components: {}
 
 
 
 
 
This is useful, but not as useful as it could be. Often you’ll want descriptions, and more in depth descriptors for the objects in the application (more similar to the first document in this blog). There are various ways of doing this. Each of the following configuration sources are applied in order:
- Configuration properties provided via the MicroProfile Config API. This allows you to do lots from disabling application scanning to including extra servers in the document.
- An OASModelReaderimplementation in the application. This provides a base document to be built upon for the final output.
- A static OpenAPI document provided in the application. This does the same as the former, but in a slightly different format.
- Annotations on the endpoint methods or object classes. This is the most idiomatic way of editing the document with minor changes.
- An OASFilterimplementation in the application. This will visit each element in the document and either remove it or edit it programmatically.
A brief example of each can be seen below. For a more detailed example utilising each of these, see the following example: https://github.com/payara/Payara-Examples/tree/master/microprofile/openapi-example.
 
The MicroProfile OpenAPI specification includes a few properties for the MicroProfile Config API. These can be included from any of the sources defined in the MicroProfile Config API. For example, in a config file stored in src/main/resources/META-INF/microprofile-config.properties.
An example configuration property might look as follows:
 
# Whether to disable the scanning of application classes
mp.openapi.scan.disable=false
 
 
 
 
 
MicroProfile OpenAPI provides two interfaces for the application developer to implement:
- org.eclipse.microprofile.openapi.OASFilter
- org.eclipse.microprofile.openapi.OASModelReader
Each of these have a similar function, but are applied at different times. An implementation of OASModelReader will create an initial OpenAPI document to build the final document from. An implementation of OASFilter will be used to visit every object in the OpenAPI document before it is published. This allows final configuration changes to be made.
When implementing each of these, the relevant interface should be implemented, and a config property should be specified in the Config API (often in microprofile-config.properties):
 
# Configure the processing classed defined to edit the OpenAPI document.
mp.openapi.model.reader=fish.payara.examples.microprofile.openapi.ModelReader
mp.openapi.filter=fish.payara.examples.microprofile.openapi.Filter
 
 
 
 
 
A static OpenAPI document file can be placed in src/main/resources/META-INF and called any of openapi.yaml, openapi.yml or openapi.json (and represented in the appropriate format of YAML or JSON). When this happens, this document will be used before any application processing. This means that if you want, you can take the document produced by the application initially, then remove any OpenAPI annotations present, edit the document as you wish and place it in the resources folder again to produce the same output!
 
MicroProfile OpenAPI defines several annotations that can be used to augment the produced OpenAPI document. These are detailed in the MicroProfile OpenAPI specification, but an example of them is as follows:
 
import javax.ws.rs.GET;
import javax.ws.rs.Path;
 
import org.eclipse.microprofile.openapi.annotations.Operation;
 
@Path("/hello")
public class TestResource {
 
    @GET
    @Operation(operationId = "hello world")
    public String helloWorld() {
        return "Hello World!";
    }
 
}
 
 
 
 
This helps make small tweaks to the produced document, and in the most non-intrusive way of editing the output.
 
The OpenAPI service is enabled by default in Payara Server and Payara Micro. The service can be controlled by two new asadmin commands. These need very little explanation, so here they are for reference!
 
set-openapi-configuration --enabled=true/false
get-openapi-configuration
 
When the OpenAPI service is disabled, no applications deployed during this period will have OpenAPI documents produced, and the endpoint will return a 403 response. A quirk of the service is that when it is enabled again, any applications deployed before it was disabled will still have their document shown, whereas any deployed while it was disabled will need redeploying. Outside of this functionality, the most recently deployed application will have it’s OpenAPI document shown.
 
The new MicroProfile Open API service in Payara Platform enables building and serving OpenAPI documents out of the box. Before the OpenAPI implementation, documents would have to be produced manually, or using an external tool and hosted as part of the application. This new integration eases the production of the document, and makes it feel more native to a MicroProfile application.
 
{{cta(‘4c7626f5-1e53-418e-90c8-add6e4af19c9’)}}
 
 
 
                     
                    
Payara will have a UI as Open Liberty has: localhost:8181/openapi/ui ?
thanks .
Hi Daniel,
Unfortunately it’s not planned yet, although I’ll raise it as an idea.
Kind regards,
Matt
Thanks for the article. If there is no UI, it would be useful to explain what can be done with the openapi document, once you have it.
Hi Martin,
The blog mentions towards the start that since the OpenAPI is a standard, the document is usable in, for example, all the Swagger suite of tools. The Swagger UI for example, can be deployed along with your application, taking the OpenAPI document as an input. The OpenAPI document itself is just a standard format document that should be readable by any relevant tool or by anyone who wants to use the REST API being documented.
Hope this helps.
Kind regards,
Matt
Matt, thanks for the article. I’m having some problems getting this to work as my Resource operation is in a project module. Our ear deployment several war modules and one EJB module. The @Operation annotation is in a class inside our API war module. Here’s what I have on my configuration:
-Dmp.openapi.servers=http://localhost:8080/company/api
-Dmp.openapi.scan.packages=com.company.api.routes
The result is the following:
openapi: 3.0.0
info:
title: Deployed Resources
version: 1.0.0
servers:
– url: http://localhost:8080/company/api
paths: {}
components: {}
No components seem to show up even though I specify to scan that package.
Would appreciate your input/help. Thanks!
Hi Brant,
The MicroProfile specification itself doesn’t support EARs as a deployment method. Because of this, applications inside EARs will most likely not be processed by the OpenAPI implementation. It may be possible however to add this support in the future. I would recommend creating a GitHub issue to add support for WARs inside EARs.
Hope this helps,
Matt
Hi,
in our project we have a problem with the generation of the Swagger UI when using inheritance:
@Schema(name = “Test1”, description = “Test1”)
public class Test1{
@Schema(description = “test1field”, example = “test1field”)
public String test1Field;
public String getTest1Field() {
return test1Field;
}
public void setTest1Field(String test1field) {
this.test1Field = test1field;
}
}
@Schema(name = “Test2”, description = “Test 2 Description.”)
public class Test2 extends Test1{
@Schema(description = “Test2 field”, example = “field”)
private String test2Field;
public String getTest2Field() {
return test2Field;
}
public void setTest2Field(String test2Field) {
this.test2Field = test2Field;
}
}
The problem is that the generated yaml under http://localhost:8080/openapi does not display the properties of the parent class and therefore they are also not included in the child class.
Test1:
description: Test1
Test2:
properties:
test2Field:
type: string
description: Test2 field
example: field
description: Test 2 Description.
allOf:
– $ref: ‘#/components/schemas/Test1’
Is there a way to fix this?
Hi Neven,
If you speak to the internal BMW person who is responsible for raising tickets, as a customer you will be able to raise your issue through there for a speedy response. Otherwise please create a Github issue. An initial guess is that the OpenAPI rewrite may solve it.