Change OpenAPI code generator to extract request objects #14217
Conversation
sdk/framework/backend.go
Outdated
| // the plugin is enabled (mounted). If specified in the request, the type | ||
| // will be used as part of the request/response body names in the OAS | ||
| // document | ||
| var requestResponsePrefix string |
There was a problem hiding this comment.
Is there a possibility of this variable staying as an empty string? And if so will that cause any problems with the spec generation?
There was a problem hiding this comment.
Yes, it is possible if whoever calls the plugin's /help endpoint does not specify the "requestResponsePrefix". In this case, the generated request name will be missing that prefix. For example "KvLookupRequest" would be replaced with just "LookupRequest". I'm not really sure what the best way of dealing with this is (or if it should be of concern). In the OpenAPI generation workflow, the prefix will always be set.
| @@ -32,6 +32,9 @@ func NewOASDocument() *OASDocument { | |||
| }, | |||
| }, | |||
| Paths: make(map[string]*OASPathItem), | |||
| Components: OASComponents{ | |||
| Schemas: make(map[string]*OASSchema), | |||
There was a problem hiding this comment.
Good job utilizing this more modern OAS concept! (reference schema components)
Yes, tested it in swagger.io 👍 |
)" This reverts commit dcb5942.
Current generated OpenAPI json
The current generated spec has request bodies anonymously defined inline:
New generated OpenAPI spec:
The new generated spec has the request bodies extracted out under
/components/schemasand referenced with$reftags. The advantage of this style is that the spec can now be used for code generation. The generated request structs will have human-readable names (e.g.KvLookupRequestin the example below):{ { "requestBody": { "content": { "application/json": { "schema": { "$ref": "#/components/schemas/KvLookupRequest" } } } } } } "components": { "schemas": { "KvLookupRequest": { "type": "object", "properties": { "token": { "type": "string", "description": "My token" } } } } }Implementation
The struct schemas are extracted individually for each plugin in
openapi.goand then combined invault/logical_system.go. Since the plugins don't have names (types) associated with them until they are mounted, we pass the plugin name to each plugin through its help endpoint within the "data" map.