On Tue, 8/1/17, Ron Ratovsky wrote:
Subject: Re: Inheritance and extension of API definitions
To: "swagger-swaggersocket@googlegroups.com"
Date: Tuesday, August 1, 2017, 1:40 AM
#yiv0345487967
#yiv0345487967 --
_filtered #yiv
r-swaggersocket@googlegroups.com"
Subject: Re: Inheritance and extension of API definitions
Thanks Ron for your answer — this is a little disappointing but good to have
our intuition confirmed.
It'd be great if such use cases were supported in the future. In a perfect
world, we'd v
will serve the
> spec with some form of authorization, and filter out the internal
> operations based on the extensions.
>
>
>
>
>
>
>
> *From: * on behalf of Julien
> Silland
> *Reply-To: *"swagger-swaggersocket@googlegroups.com" <
> swagger-sw
filter out the internal operations based on the
extensions.
From: on behalf of Julien Silland
Reply-To: "swagger-swaggersocket@googlegroups.com"
Date: Friday, July 28, 2017 at 15:59
To: Swagger
Subject: Inheritance and extension of API definitions
Hello,
My company r
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
