It would be quite handy, if multiple sets of OpenAPI could be generated, so each client/service can have their own APIs documented and accessible in the OCS API viewer.
E.g. in Talk we have multiple different API consumers and I would like to document and generate documentation for all of them in one way only:
Proposal
Similar to PHPUnits Group attribute and the already used IgnoreOpenAPI, we could also introduce an OpenAPI(scope: XYZ) attribute.
The openapi-extractor would then group the routes into different files and the ocs-api-viewer would show:
- spreed - All controller methods without
IgnoreOpenAPI or with OpenAPI or with OpenAPI(scope: default)
- spreed-admin - All controller methods with
OpenAPI(scope: admin)
- spreed-signaling - All controller methods with
OpenAPI(scope: signaling)
- spreed-recording - All controller methods with
OpenAPI(scope: recording)
- spreed-sip - All controller methods with
OpenAPI(scope: sip)
Depending on the discussion I can also imagine to look into this.
It would be quite handy, if multiple sets of OpenAPI could be generated, so each client/service can have their own APIs documented and accessible in the OCS API viewer.
E.g. in Talk we have multiple different API consumers and I would like to document and generate documentation for all of them in one way only:
Proposal
Similar to PHPUnits
Groupattribute and the already usedIgnoreOpenAPI, we could also introduce anOpenAPI(scope: XYZ)attribute.The openapi-extractor would then group the routes into different files and the ocs-api-viewer would show:
IgnoreOpenAPIor withOpenAPIor withOpenAPI(scope: default)OpenAPI(scope: admin)OpenAPI(scope: signaling)OpenAPI(scope: recording)OpenAPI(scope: sip)Depending on the discussion I can also imagine to look into this.