...
ID | IEP-87 | ||||||||
Author | |||||||||
Sponsor | |||||||||
Created |
| ||||||||
Status |
|
Table of Contents |
---|
Open API is the most popular approach to design, build and document REST APIs. It does not depend on a particular language. The contract provided by the Swagger (Open API implementation) guarantees that the REST server is compatible with the specification. The specification is the single source of truth for consumers (web interface, CLI, third party integrations).
The current implementation does not support auto-generation for the API specification. The main value of this improvement is to add the possibility to generate the API specification from code.
Code-first approach is suggested. One writes backend code and after that, the specification is generated from this code.
...
any other module that wants to expose an enpoint:
...
:
...
...
Info | ||
---|---|---|
| ||
IMPORTANT: Additional dependencies here mean that Java Code Style Best Practices (3d party libraries) are going to be adjusted: Micrionaut for REST, Swagger for Open API annotations, and Micronaut serde for REST serialization. |
The API specification is a new artifact that will be introduced during the build time. This file should be placed in the source code under modules/ignite-rest/openapi/openapi.yaml
path.
Changes in API should not introduce breaking changes for the clients and the API version won't change. In case the breaking change is necessary, then new openapi-v2.yaml should be generated.
Info | ||
---|---|---|
| ||
Note that an Open API spec has a version field itself. This field is the specification file version but not the API version. The minor value should be incremented when any backward compatible change is introduced. The major value should be incremented when the breaking change is introduced. |
Example of API evolution:
/api/v1
. API version 1, openapi.yaml#version: 1.0./api/v1
. API version 1, openapi.yaml#version: 1.1/api/v1
, so introduce /api/v2.
API version 2, openapi-v2.yaml#version: 2.0, openapi.yaml#version: 1.1.Ignite modules can provide endpoints that will be included into the netty server by RestComponent at the build time. For example, the configuration module exposes /management/v1/configuration/node by declaring NodeConfigurationController and NodeConfigurationRestFactory. Then ignite-configuration module is added as a dependency for the ignite-rest module. And NodeConfigurationController is added to @OpenAPIInclude annotation in RestComponent.
"build time" means that the micronaut annotation processor will discover classes annotated with io.micronaut.http.annotation.Controller
and register them as request handlers at server bootstrap.
This is done by default but it is always possible to register request handlers at runtime.
Here is a discussion about adding 3rd party dependencies (micronaut and swagger). The main advantages of micronaut:
The last point is important. Ignite 3 will definitely need to implement security protocols and strategies. Micronaut already has implementations for the most popular ones (OAuth2/OpenID, LDAP, etc), they are tested in production by a community and have a little chance to introduce a vulnerability to the server compering with our own implementation. All these standards are going to be implemented in Ignite 3.
Code Block | ||||
---|---|---|---|---|
| ||||
@OpenAPIDefinition( info = @Info( title = "Ignite REST module", version = "3.0.0-alpha", license = @License(name = "Apache 2.0", url = "https://ignite.apache.org"), contact = @Contact(email = "dev@ignite.apache.org") ) ) @OpenAPIInclude(classes = {ClusterConfigurationController.class, NodeConfigurationController.class}) // include to openapi specification public class RestComponent implements IgniteComponent { // ... public RestComponent(List<MicronautFactory> micronautFactories, RestConfiguration restConfiguration) { // register all factories in micronaut context } @Override public void start() { // start REST server } |
...
Info |
---|
Configuration API already exists in Apache Ignite 3. |
This REST group provides methods to read and update node/cluster configuration.
Method | Path | Parameters | Description |
---|---|---|---|
GET | /management/v1/configuration/node/ | Return node configuration in HOCON format | |
GET | /management/v1/configuration/node/{configPath} |
| Return node configuration subtree in HOCON format specified with configPath parameter. |
PATCH | /management/v1/configuration/node/ |
| Update Patch node configuration with a given body. |
GET | /management/v1/configuration/cluster/ | Return cluster configuration in HOCON format. | |
GET | /management/v1/configuration/cluster/{configPath} |
| Return cluster configuration subtree in HOCON format specified with configPath parameter. |
PATCH | /management/v1/configuration/cluster/ |
| Update Patch cluster configuration with a given body. |
Info |
---|
Management API already exists in Apache Ignite 3. |
Manage cluster state.
Method | Path | Parameters | Description |
---|---|---|---|
POST | /management/v1/cluster/init/ |
| Initialize cluster |
Meta storage and cmg definitions.
Provide information about cluster topology.
Method | Path | Parameters | Description |
---|---|---|---|
GET | /management/v1/topology/physical | Return physical cluster topology information(consistent ID, ID, address, status). |
Method | Path | Parameters | Description |
---|---|---|---|
GET | /management/v1/topology/logical | Return logical cluster topology information(consistent ID, ID, address, status). |
...
Method | Path | Parameters | Description |
---|---|---|---|
GET | /management/v1/node/version/ | Return node build version in semver format. |
...