Currently the extension's public API does not align with Vault's actual API. This is done by mapping the Vault API model objects to public extension API objects. This is fine and allowing smoothing out some of the rough edges in Vault's API.
Unfortunately this means a lot of duplicated work when adding missing APIs or updated existing APIs to support newer Vault versions.
Solution
All this means that regardless of the extension's public API, the "internal" clients use DTOs that map 1:1 to the associated Vault API.
We need to start generating these DTOs from the OpenAPI spec for Vault; which can be generated for any Vault version using it's "self describing" endpoint /sys/internal/specs/openapi. Related docs are here
Implementation
Although these model objects are public (for packaging reasons) they are "internal" and only used by the "Internal" engine classes. Given this, we should be able to get an existing OpenAPI Java generator to produce suitable classes we can use; the shape of these classes can change dramatically without affecting extension users.
Problem
Currently the extension's public API does not align with Vault's actual API. This is done by mapping the Vault API model objects to public extension API objects. This is fine and allowing smoothing out some of the rough edges in Vault's API.
Unfortunately this means a lot of duplicated work when adding missing APIs or updated existing APIs to support newer Vault versions.
Solution
All this means that regardless of the extension's public API, the "internal" clients use DTOs that map 1:1 to the associated Vault API.
We need to start generating these DTOs from the OpenAPI spec for Vault; which can be generated for any Vault version using it's "self describing" endpoint
/sys/internal/specs/openapi
. Related docs are hereImplementation
Although these model objects are public (for packaging reasons) they are "internal" and only used by the "Internal" engine classes. Given this, we should be able to get an existing OpenAPI Java generator to produce suitable classes we can use; the shape of these classes can change dramatically without affecting extension users.