frankframework
Group one or more ApiListeners to form an API
Related Problem or Business Case
Currently it is a bit difficult to have multiple distinct API implementations within a single FF instance.
Describe the Feature
The grouping of ApiListeners to form an API could simply be "all ApiListeners within a configuration form an API". I think this approach can have many advantages towards isolation between configurations and reusablity.
Subpath per API
Distinct API's should have their own subpath such as /<api-name>/v1. The major-version in the uri is already a requirement of the Dutch API Design Rules (https://gitdocumentatie.logius.nl/publicatie/api/adr/1.0/#api-20) for example. Additionally, these subpaths should not be part of the 'uriPattern' of ApiListeners, because they would be included in the 'path' of the generated OpenApi spec. Using ApiServlet subpath for this is also not a viable option, because it doesnt prevent collisions when multiple api's use the same endpoint, such as the endpoint that serves the OpenApi spec.
OpenApi spec per API
Each distinct API should have it's own OpenApi spec. Commonly the OpenApi spec is served on /<api-name>/v1/openapi.<json | yaml> or /<api-name>/v1/schemas/openapi.<json | yaml>, the former being a requirement in Dutch API Design Rules (https://gitdocumentatie.logius.nl/publicatie/api/adr/1.0/#api-51). This also specifies that different major-versions of an API should serve it's own OpenApi spec, reinforcing the need for subpaths per API. Preferably the endpoint that serves the OpenApi spec is configurable. Ideally, by default, the generated OpenApi spec is served, but it would be nice if there is an option to override it with your own OpenApi spec file, at least till it is possible to fully provide documentation for all elements within the OpenApi spec in-code.
Tag ApiListeners It should be possible to logically group endpoints/ApiListeners. In the OpenApi spec this is done with 'tags'. Tags are used to group endpoints into collections.
Security configuration per API Each API should have the ability to be configured with different authentication methods. Preferably the authentication method(s) are configured at a single place for a specific API, which is then also automatically used to generate the 'security' section of the OpenApi spec. Individual ApiListeners of an API should only contain security details specific to that endpoint, such as required scopes, roles, group, etc. They should also automatically be part of the generated OpenApi spec.
Collaboration with External Companies
No, community resolution only
Anything else?
No response
