Even though OAS 2.0 support is deprecated, we should carefully handle the use cases of OAS 2.0 supported APIs which have been migrated from previous versions. In that case, still, we have to maintain the current implementation(Both in UI and backend) to handle functionalities of two versions.
@Rajith Roshan <[email protected]> , @Praminda Jayawardana <[email protected]> How this would affect micro gateway? On Tue, Aug 13, 2019 at 2:21 PM Dushan Silva <[email protected]> wrote: > Hi, > I also think since this is a major release it is a good time to move 3.0.0 > however if we think from users perspective we should consider the however > not supporting 2.0 would effect. If we are planning on supporting a > conversion between 2.0 to 3.0 then definitely +1 for this. > > Thanks > > On Mon, Aug 12, 2019 at 12:08 PM Malintha Amarasinghe <[email protected]> > wrote: > >> >> >> On Mon, Aug 12, 2019 at 11:21 AM Rukshan Premathunga <[email protected]> >> wrote: >> >>> >>> >>> On Mon, Aug 12, 2019 at 11:16 AM Thilini Shanika <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Mon, Aug 12, 2019 at 10:53 AM Rukshan Premathunga <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> ATM generated API definition is in swagger 2. Can we make it OAS 3 for >>>>> the new APIs? >>>>> >>>> Yes, we can change the default version of a newly created API to OAS >>>> 3.0.0. However, the API creator is allowed to pick the OAS version(OAS 2 or >>>> 3) of the API during API creation time. Are you suggesting to remove the >>>> default support for OAS 2.0(For newly designed APIs)? >>>> >>> Yes, my suggestion is, if a user doesn't have an OAS definition, >>> generate an OAS 3 definition for them. If they have an OAS definition, >>> allowing them to import OAS 2 or 3 definition. So we will maintain the same >>> OAS version afterward. >>> >> >> I also think this would be okay. If anyone wants to stick with OAS 2.0, >> they have an import OAS 2.0 option. >> Maintaining two different API designers at UI level would not be good in >> terms of maintenance. We would one day anyway have to move to the designer >> to 3.0.0 as we did for 1.2 -> 2.0 in the past. Since this is a major >> release, this is a good time to do it as Pubudu said. @Rukshan >> Premathunga <[email protected]>, if we move to 3.0.0, can we completely >> remove the UI designer code used for 2.0 and keep only 3.0.0 related code? >> >> Thanks! >> >>> >>> >> When new API is created from an OAS 2 or 3, we can create from the same >>>>> imported version. Existing API also can be kept as an existing version. >>>>> >>>>> Thanks and Regards >>>>> >>>>> -- >>>>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc. >>>>> (m) +94711822074 | (w) +94112145345 | Email: [email protected] >>>>> GET INTEGRATION AGILE >>>>> Integration Agility for Digitally Driven Business >>>>> >>>> >>>> >>>> -- >>>> Thilini Shanika >>>> Associate Technical Lead >>>> WSO2, Inc.; http://wso2.com >>>> 20, Palmgrove Avenue, Colombo 3 >>>> >>>> >>>> >>> >>> -- >>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc. >>> (m) +94711822074 | (w) +94112145345 | Email: [email protected] >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> >> >> >> -- >> Malintha Amarasinghe >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> > > > -- > Best Regards > Dushan Silva > Software Engineer > > *WSO2, Inc. * > > lean . enterprise . middleware > Mob: +94 774 979042 > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > -- Thilini Shanika Associate Technical Lead WSO2, Inc.; http://wso2.com 20, Palmgrove Avenue, Colombo 3
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
