Hello,
My company runs an API that we surface to three distinct audiences: third
party developers, partners and first party clients. What this segmentation
means in practice is that depending on the nature of the clients, a given
endpoint might be available to you or not, and it if is available, the
response might be more or less rich.
We are just getting around to completing the Swagger specification of our
public API and eager to publish that. We also have a goal to consume a
Swagger spec to generate clients and documentation for partners and
internal customers. For confidentiality reasons, we'd prefer keeping the
internal endpoints and payloads out of the public definition.
Swagger comes out of the box with support for inheriting models and we're
thinking of taking advantage of that to formalize responses returned by
non-public endpoints:
{
"InternalFoo": {
"allOf": [
{
"$ref": "foo.json#/PublicFoo"
},
{
"properties": {
…
}
]
}
}
What I'm trying to see is whether we could apply the same approach for
extending the public API with partner and internal endpoints — ideally, we'd
keep maintaining the external Swagger spec as is and the internal one would
"inherit" from it and automatically benefit from additions to it, all the while
accommodating the redefinition of certain response types and the addition of
certain endpoints. At a fundamental level, what I'm trying to accomplish is:
swagger-internal.json
{
"$ref": "swagger.json",
"paths": {
"/foo/{id}": {
"get": {
"responses": {
"200": {
"schema": {
"$ref": "internal-foo.json#/InternalFoo"
}}}}}}
},
Is such a thing supported at all by the tooling? Is there a different model we
could follow to accomplish this?
Thanks,
-Julien
--
You received this message because you are subscribed to the Google Groups
"Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to swagger-swaggersocket+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
