Eclipse MicroProfile OpenAPI API
The Payara Platform 6.2024.8 provides MicroProfile OpenAPI 3.1
Background
OpenAPI was designed to provide a standard interface for documenting and exposing RESTful APIs. The MicroProfile OpenAPI API provides a set of interfaces and annotations to allow application developers to produce an OpenAPI document from their JAX-RS applications. OpenAPI is somewhat similar to the Swagger API, so many concepts in the API will be familiar.
The complete specification can be found on the Eclipse MicroProfile website.
Breaking changes introduced in MicroProfile OpenAPI 3.1 are listed in the official specification under Incompatible Changes
Version 3.1 of the OpenAPI specification does not define the behaviour of implementations where multiple applications are deployed to the same container. This limitation will be addressed in a later version of the OpenAPI specification. Payara Server allows you to see multiple applications in the OpenAPI document, see multiple applications. |
REST Endpoint
MicroProfile OpenAPI specifies that an OpenAPI document should be published at the endpoint /openapi
documenting a deployed application. For both Payara Server and Payara Micro, this means that the endpoint can be found on any HTTP port (e.g. 8080
) after deploying an application.
The OpenAPI document displayed will always be for the most recently deployed application, except in the special case of disabling the service. |
By default, the OpenAPI document is displayed in YAML format, although this can be changed to JSON by changing the Accept
header of the request. Alternatively if using a browser, this can also be done by specifying a format
query parameter.
For example, http://localhost:8080/openapi?format=json
. The valid values are json
and yaml
.
OpenAPI Configuration Sources
MicroProfile OpenAPI specifies several ways of configuring the data in the produced OpenAPI document. These are all provided by the OpenAPI API artifact:
<dependency>
<groupId>org.eclipse.microprofile.openapi</groupId>
<artifactId>microprofile-openapi-api</artifactId>
<version>{mpOpenAPIVersion}</version>
<scope>provided</scope>
</dependency>
Configuration Properties
The OpenAPI document generation process can be configured through the Config API. The following are the standard configuration properties as presented by the specification:
Property key | Description |
---|---|
|
Configuration property to specify the fully qualified name of the OASModelReader implementation. |
|
Configuration property to specify the fully qualified name of the OASFilter implementation. |
|
Configuration property to disable annotation scanning. Default value is |
|
Configuration property to specify the list of packages to scan. For example,
|
|
Configuration property to specify the list of classes to scan. For example,
|
|
Configuration property to specify the list of packages to exclude from scans. For example,
|
|
Configuration property to specify the list of classes to exclude from scans. For example,
|
|
Configuration property to specify the list of global servers that provide connectivity information. For example,
|
|
Prefix of the configuration property to specify an alternative list of servers to service all operations in a path. For example,
|
|
Prefix of the configuration property to specify an alternative list of servers to service an operation.
Operations that want to specify an alternative list of servers must define an |
|
Prefix of the configuration property to specify an alternative list of servers to service an operation.
Prefix of the configuration property to specify a schema for a specific class, in JSON format. The remainder of the property key must be the fully-qualified class name. The value must be a valid OpenAPI schema object, specified in the JSON format. The use of this property is functionally equivalent to the use of the When a For example, in the case where an application wishes to represent a Java
|
In addition to the standard properties, the following properties have been added as extensions within the Payara Platform:
Property key |
Description |
|
Configuration property that allows the server to scan packaged JAR files inside the WAR’s library directory ( |
OASModelReader
org.eclipse.microprofile.openapi.OASModelReader
The OASModelReader interface can be implemented by an application developer. It must then be declared as a Config API variable in the form:
mp.openapi.model.reader=fish.payara.examples.OASModelReaderImpl
This class will be called at the beginning of the OpenAPI document generation, and will create the initial OpenAPI document.
OASFilter
org.eclipse.microprofile.openapi.OASFilter
The OASFilter interface can be implemented by an application developer. It must then be declared as a Config API variable in the form:
mp.openapi.filter=fish.payara.examples.OASFilterImpl
Each method in the implementation will be called on every appropriate element in the OpenAPI model. For example, the method filterPathItem(PathItem pathItem)
will be called for every PathItem
in the document.
This class is called last, before the document is published.
Static Document
The MicroProfile OpenAPI supports using a static OpenAPI document to build from. This static file can be placed in either META-INF
directory in a WAR file. Most often, this means putting the file in src/main/resources/META-INF
.
The following file names are allowed for this file. The file given must also be in the specified format.
File Format |
Allowed File Names |
|
|
|
|
Annotations
The MicroProfile OpenAPI API provides many annotations to use to augment the OpenAPI document. These are detailed in the OpenAPI Specification. These annotations are applied before the OASFilter.
Example
The following code could be used to give the corresponding operation an ID of "hello world".
import org.eclipse.microprofile.openapi.annotations.Operation;
@Path("/app")
public class AppResource{
@GET
@Operation(operationId = "hello world")
public String helloWorld() {
return "Hello World!";
}
}
- Here’s an example of how the OpenAPI document of a sample application would look like
openapi: 3.0.0
info:
title: A Test Application
version: "1.0"
servers:
- url: http://localhost:8080/openapi-example-1.0
description: Default Server.
- url: https://localhost:8181/openapi-example-1.0
description: Default Server.
paths:
/api/hello:
get:
operationId: hello-world
responses:
default:
content:
text/plain:
schema:
type: string
description: Default Response.
deprecated: false
endpoints:
/openapi-example-1.0:
- /api/hello
components: {}
Deployed Endpoints
When more than one application is deployed, a merge is done in the OpenAPI document. The resulting document will contain all application and path definitions present. To improve the its readability, an endpoints
attribute which lists all deployed endpoints grouped by their application context roots has been added to the document.
The endpoints attribute is an proprietary Payara Platform extension and it’s not portable.
|
- The following example shows an OpenAPI document generated when 2 different applications are deployed
openapi: 3.0.0
info:
title: Deployed Resources
version: 1.0.0
servers:
- url: http://localhost:8080/ClusteredSingleton
description: Default Server.
- url: https://localhost:8181/ClusteredSingleton
description: Default Server.
- url: http://localhost:8080/SimpleWAR
description: Default Server.
- url: https://localhost:8181/SimpleWAR
description: Default Server.
paths:
/resources/javaee8:
get:
operationId: ping
responses:
default:
content:
'*/*':
schema:
type: object
description: Default Response.
/resources/randomNumberGen:
get:
operationId: randomNumberGen
responses:
default:
content:
'*/*':
schema:
type: integer
description: Default Response.
/rest/request:
get:
operationId: getXml
responses:
default:
content:
text/plain:
schema:
type: string
description: Default Response.
put:
operationId: putXml
requestBody:
content:
application/xml:
schema:
type: string
responses:
default:
content:
'*/*':
schema:
type: object
description: Default Response.
endpoints:
/ClusteredSingleton:
- /resources/javaee8
- /resources/randomNumberGen
/SimpleWAR:
- /rest/request
components: {}
OpenAPI Configuration
On Payara Server, MicroProfile OpenAPI settings can be configured by using the Admin Console or Asadmin CLI commands.
Using the Admin Console
To configure the OpenAPI in the Admin Console, go to Configuration → [instance-configuration (like server-config
)] → MicroProfile → OpenAPI:
Using Asadmin Commands
Use the following commands to configure the settings of the MicroProfile OpenAPI service:
Security Configuration
By default, the OpenAPI endpoint binds to the root context application which is the default-web-module
(also known as docroot
) system application and the default-web-module
application, which is secured under the default realm (file
) of the server.
If a user application is deployed in the empty context-root, then the security configuration of this application will be shared by the OpenAPI endpoint, so exert extreme caution when making these changes.
Upgrading from MicroProfile 3.x to 4.x
MicroProfile 4.0 brings with it a number of changes to MicroProfile OpenAPI, among these changes are some which break previous behaviour. The breaking changes are primarily to do with the removal of a number of methods previously marked as deprecated from the API, and only affect the use of OpenAPI programmatically (there are no breaking changes pertaining to the use of the annotations).
-
Scopes
interface removed - UseMap<String, ServerVariable>
. -
ServerVariables
interface removed - UseMap<String, ServerVariable>
. -
The following interfaces no longer extend
Map
- Ensure you are not using any of the methods or functionality gained from theMap
class:-
APIResponses
-
get(Object key)
- UsegetAPIResponse(String)
. -
containsKey(Object key)
- UsehasAPIResponse(String)
. -
put(String key, PathItem value)
- UseaddAPIResponse(String, APIResponse)
. -
putAll(Map<? extends String, ? extends APIResponse> m)
- UsesetAPIResponses(Map)
. -
remove(Object key)
- UseremoveAPIResponse(String)
.
-
-
Callback
-
get(Object key)
- UsegetPathItem(String)
. -
containsKey(Object key)
- UsehasPathItem(String)
. -
put(String key, PathItem value)
- UseaddPathItem(String, PathItem)
. -
putAll(Map<? extends String, ? extends PathItem> m)
- UsesetPathItems(Map)
. -
remove(Object key)
- UseremovePathItem(String)
.
-
-
Content
-
get(Object key)
- UsegetMediaType(String)
. -
containsKey(Object key)
- UsehasMediaType(String)
. -
put(String key, MediaType value)
- UseaddMediaType(String, MediaType)
. -
putAll(Map<? extends String, ? extends MediaType> m)
- UsesetMediaTypes(Map)
. -
remove(Object key)
- UseremoveMediaType(String)
.
-
-
Path
-
get(Object key)
- UsegetPathItem(String)
. -
containsKey(Object key)
- UsehasPathItem(String)
. -
put(String key, PathItem value)
- UseaddPathItem(String, PathItem)
. -
putAll(Map<? extends String, ? extends PathItem> m)
- UsesetPathItems(Map)
. -
remove(Object key)
- UseremovePathItem(String)
.
-
-
SecurityRequirement
-
get(Object key)
- UsegetScheme(String)
. -
containsKey(Object key)
- UsehasScheme(String)
. -
put(String key, List<String> value)
- UseaddScheme(String, List<String>)
. -
putAll(Map<? extends String, ? extends List<String> m)
- UsesetSchemes(Map)
. -
remove(Object key)
- UseremoveScheme(String)
.
-
-
-
A number of methods have been removed from model interfaces, in addition to those above:
-
OASFactory
-
createScopes
- useMap<String, String>
. -
createServerVariables
- useMap<String, ServerVariable>
.
-
-
OAuthFlow
-
setScopes(Scopes scopes)
- UsesetScopes(Map)
. -
scopes(Scopes scopes)
- Usescopes(Map)
.
-
-
OpenAPI
-
path(String name, PathItem path)
- usePaths#addPathItem(String, PathItem)
onOpenAPI#getPaths
-
-
PathItem
-
readOperations
- useMap#values()
onPathItem#getOperations()
. -
readOperationsMap
- usegetOperations()
.
-
-
Schema
-
getAdditionalProperties
- usegetAdditionalPropertiesSchema()
orgetAdditionalPropertiesBoolean()
. -
setAdditionalProperties(Schema additionalProperties)
- usesetAdditionalPropertiesSchema(Schema)
. -
setAdditionalProperties(Boolean additionalProperties)
- usesetAdditionalPropertiesBoolean(Boolean)
. -
additionalProperties(Schema additionalProperties)
- useadditionalPropertiesSchema(Schema)
. -
additionalProperties(Boolean additionalProperties)
- useadditionalPropertiesBoolean(Boolean)
.
-
-
Server
-
setVariables(ServerVariables variables)
- UsesetVariables(Map)
. -
variables(ServerVariables variables)
- Usevariables(Map)
.
-
-