Knot.x defines two routes for processing requests:
the templating engine that processes templates from repositories and injects data from external services
Gateway API that allows you to create and expose REST API
This approach requires deep Knot.x knowledge to define a simple REST API interface. Additionally there is no validation mechanism for contracts.
Expected solution:
We want to use Open API 3 specification directly inside Knot.x code using design first approach. Additionally all request processors (handlers) should be configurable. Project specific processors should be easily configurable in routing configuration.
Example case:
The template repository authorizes requests based on the authentication header. This header comes from a cookie or (if it is not found) an external service (soft authentication / anonymous authentication). Thus, a custom authentication handler can be coded and configured before calling the repository.
The same authentication handler can be used in the Gateway API (for both custom flow and dedicated server).
IMPLEMENTATION IN PROGRESS
Version used
Context of the issue/feature
The current approach:
Knot.x defines two routes for processing requests:
Expected solution:
We want to use Open API 3 specification directly inside Knot.x code using design first approach. Additionally all request processors (handlers) should be configurable. Project specific processors should be easily configurable in routing configuration.
Example case:
The template repository authorizes requests based on the authentication header. This header comes from a cookie or (if it is not found) an external service (soft authentication / anonymous authentication). Thus, a custom authentication handler can be coded and configured before calling the repository.
The same authentication handler can be used in the Gateway API (for both custom flow and dedicated server).
Appendix