Re: [Architecture] [Dev] OAS 3 as default API definition

[Dushan Silva]

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 
wrote:

>
>
> On Mon, Aug 12, 2019 at 11:21 AM Rukshan Premathunga 
> wrote:
>
>>
>>
>> On Mon, Aug 12, 2019 at 11:16 AM Thilini Shanika 
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 12, 2019 at 10:53 AM Rukshan Premathunga 
>>> 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
> ,  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: ruks...@wso2.com
 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: ruks...@wso2.com
>> 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
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Best Regards
Dushan Silva
Software Engineer

*WSO2, Inc. *

lean . enterprise . middleware
Mob: +94 774 979042
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] OAS 3 as default API definition

[Rukshan Premathunga]

On Tue, Aug 13, 2019 at 7:39 PM Rajith Roshan  wrote:

>
>
> On Tue, Aug 13, 2019 at 2:48 PM Thilini Shanika  wrote:
>
>> 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  , @Praminda Jayawardana
>> 
>> How this would affect micro gateway?
>>
> Microgateway handles the swagger parsing based on the swagger version.
> When APIs are imported from api manager it will , check the swagger version
> and use the correct parser. So I don't think this would be an issue.
>
had a discussion with Thilini and Praminda, and noticed MG use V3 parser.
But it seems v3 parser doesn't validate the content but parse the
definition with existing information. I think it is not enough for this use
case. I think we need to use both v2 and v3 parser after identifying the
OAS version. ATM we have parsed the definition with both v2 and v3 to
identify the correct OAS version. @Rajith Roshan   what
is the mechanism you have used to identify the version.
If there anything in the current approach, please suggest if there are any
other alternatives.

>
>> On Tue, Aug 13, 2019 at 2:21 PM Dushan Silva  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 <
>>> malint...@wso2.com> wrote:
>>>


 On Mon, Aug 12, 2019 at 11:21 AM Rukshan Premathunga 
 wrote:

>
>
> On Mon, Aug 12, 2019 at 11:16 AM Thilini Shanika 
> wrote:
>
>>
>>
>> On Mon, Aug 12, 2019 at 10:53 AM Rukshan Premathunga <
>> ruks...@wso2.com> 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 ,  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?

>>> We need to keep both v2 and v3 support in UI right? Because still, we
need to support existing v2 APIs.

>
 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: ruks...@wso2.com
>>> 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: ruks...@wso2.com
> 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
 d...@wso2.org
 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
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>> Thilini 

Re: [Architecture] [Dev] OAS 3 as default API definition

[Rajith Roshan]

On Tue, Aug 13, 2019 at 2:48 PM Thilini Shanika  wrote:

> 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  , @Praminda Jayawardana
> 
> How this would affect micro gateway?
>
Microgateway handles the swagger parsing based on the swagger version. When
APIs are imported from api manager it will , check the swagger version and
use the correct parser. So I don't think this would be an issue.

>
> On Tue, Aug 13, 2019 at 2:21 PM Dushan Silva  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 
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 12, 2019 at 11:21 AM Rukshan Premathunga 
>>> wrote:
>>>


 On Mon, Aug 12, 2019 at 11:16 AM Thilini Shanika 
 wrote:

>
>
> On Mon, Aug 12, 2019 at 10:53 AM Rukshan Premathunga 
> 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 ,  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: ruks...@wso2.com
>> 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: ruks...@wso2.com
 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
>>> d...@wso2.org
>>> 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
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Thilini Shanika
> Associate Technical Lead
> WSO2, Inc.; http://wso2.com
> 20, Palmgrove Avenue, Colombo 3
>
>
>

-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] OAS 3 as default API definition

[Thilini Shanika]

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  , @Praminda Jayawardana

How this would affect micro gateway?

On Tue, Aug 13, 2019 at 2:21 PM Dushan Silva  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 
> wrote:
>
>>
>>
>> On Mon, Aug 12, 2019 at 11:21 AM Rukshan Premathunga 
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 12, 2019 at 11:16 AM Thilini Shanika 
>>> wrote:
>>>


 On Mon, Aug 12, 2019 at 10:53 AM Rukshan Premathunga 
 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 ,  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: ruks...@wso2.com
> 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: ruks...@wso2.com
>>> 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
>> d...@wso2.org
>> 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
> d...@wso2.org
> 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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture