You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Admin APIs - Arguable, but from the HPB, Turn, Sturn, SIP and other management is not really something a normal mobile client should/would implement, yet it's shown in the API docs and a bit confusing, or there is no documentation available for the frontenders that implement the admin settings UI
Signaling server API - We have some endpoints that only the signaling server can access with a shared secret
Hosted signaling server API - We have some endpoints that are used when trying to sign up with a hoster of signaling servers
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.
The text was updated successfully, but these errors were encountered:
In general I agree with this idea. This also appeared in other apps where different consumers of the API exist. I'll think a bit about the implementation and will reply here.
One thing that just came to my mind is that we might want to use standardized groups. For example one group is always for clients, one for federated servers and so on. I don't know which groups would make sense, but those two are definitely appearing in multiple apps.
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 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:
IgnoreOpenAPI
or withOpenAPI
or 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.
The text was updated successfully, but these errors were encountered: