Re: [Architecture] How are we planing to support API versioning in v3

[Nuwan Dias]

On Fri, Mar 22, 2019 at 2:17 AM Nuwan Bandara  wrote:

> Hi All,
>
> I stumbled upon one of Roy Fielding tweets -
> https://twitter.com/fielding/status/376835835670167552 :)
>

I unfortunately don't agree with this tweet :). I don't understand how
having a v1 makes your API non-evolvable. IMO the sole purpose of having v1
is to say the API will/should evolve to v2, v3, likewise.

>
> and started digging bit on api versioning. Right now we encourage API-M
> users to make API versions explicit in the API URI. which means a sample
> URI is /{context}/{version}/{resource}
>
> example: /pizzahut/v1/order
>
> however this is not the best option. We are gateway providers, IMO we
> should give options.
>

We give an option to omit the version from the URI by marking the API as
the default version to route to. So you can access this API through
/pizzahut/order (no need v1). The gateway will route the request to
whatever version is selected as primary (default).

>
> some good alternatives are allow API developers to use headers to
> communicate version info like
>
> GET /pizzahut/order
> Accept: application/vnd.pizza.order.v1+json
>
> or something similar.
>
> I know we can handle custom headers in mediation, but we should provide
> this by default, maybe provide that as the default option rather than URL
> based explicit option.
>
> Some good reading -
> https://www.mnot.net/blog/2012/12/04/api-evolution.html
>
> Regards,
> /Nuwan
>
> --
>
>
> *Thanks & Regards,*
> *Nuwan Bandara | Director - **Solutions Architecture,  WSO2 Inc.*
> *+1 646 643 8618 | +1 650 745 2169 Ext 4212 | http://nuwanbando.com
>  *
> 
>


-- 
*Nuwan Dias* | Director | WSO2 Inc.
(m) +94 777 775 729 | (e) nuw...@wso2.com
[image: Signature.jpg]
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] How are we planing to support API versioning in v3

[Nuwan Bandara]

Hi All,

I stumbled upon one of Roy Fielding tweets -
https://twitter.com/fielding/status/376835835670167552 :)

and started digging bit on api versioning. Right now we encourage API-M
users to make API versions explicit in the API URI. which means a sample
URI is /{context}/{version}/{resource}

example: /pizzahut/v1/order

however this is not the best option. We are gateway providers, IMO we
should give options.

some good alternatives are allow API developers to use headers to
communicate version info like

GET /pizzahut/order
Accept: application/vnd.pizza.order.v1+json

or something similar.

I know we can handle custom headers in mediation, but we should provide
this by default, maybe provide that as the default option rather than URL
based explicit option.

Some good reading - https://www.mnot.net/blog/2012/12/04/api-evolution.html

Regards,
/Nuwan

-- 


*Thanks & Regards,*
*Nuwan Bandara | Director - **Solutions Architecture,  WSO2 Inc.*
*+1 646 643 8618 | +1 650 745 2169 Ext 4212 | http://nuwanbando.com
 *

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

[Architecture] WSO2 Identity Server 5.8.0-alpha Released!

[Hasanthi Purnima Dissanayake]

WSO2 Identity and Access Management team is pleased to announce the release
of Identity Server 5.8.0 alpha!
Download

You can download WSO2 Identity Server 5.8.0 alpha from here

.

You can download WSO2 Identity Server Analytics 5.8.0 alpha from here

.
How to run

   1.

   Extract the downloaded zip file.
   2.

   Go to the bin directory in the extracted folder.
   3.

   Run the wso2server.sh file if you are on a Linux/Mac OS or run the
   wso2server.bat file if you are on a Windows OS.
   4.

   Optionally, if you need to start the OSGi console with the server, use
   the -DosgiConsole property when starting the server.

What's new in WSO2 Identity Server 5.8.0 alpha

A list of all the new features and bug fixes shipped with this release can
be found here 

Known Issues

All the open issues pertaining to WSO2 Identity Server are reported at the
following location:

   -

   IS Runtime 
   -

   IS Analytics 

Contribute to WSO2 Identity ServerMailing Lists

Join our mailing lists and correspond with the developers directly. We also
encourage you to take part in discussions related to the product in the
architecture mailing list. If you have any questions regarding the product
you can use our StackOverflow forum to raise them as well.

   -

   Developer List: d...@wso2.org
   -

   Architecture List: architecture@wso2.org
   -

   User Forum: StackOverflow
   

Reporting Issues

We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server GIT
Issues .

For more information about WSO2 Identity Server, please see https://wso2
.com/identity-and-access-management or visit the WSO2 Oxygen Tank
 developer portal for additional resources.

~ The WSO2 Identity and Access Management Team ~

-- 

Hasanthi Dissanayake

Senior Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM - Microgateway] Restructuring the Microgateway Project Folder Structure and Command Execution to Support Multiple APIs

[Viraj Gamage]

Will change the endpoint configuration as suggested by @Pubudu Gunatilaka
 . It seems to be more convenient in terms of user
experience.

Thank you,
Viraj

On Thu, Mar 21, 2019 at 3:49 PM Viraj Gamage  wrote:

> Hi Pubudu,
>
> IMO, It doesn't seem possible to bring all three fields into one generic
> type. If I elaborate further,
>
>
>- For loadbalance type
>   - there should be an array of endpoints
>- For failover type
>   - single url and a set of failover endpoints
>- For default type
>   - single url
>
> we can bring default type and loadbalance into one generic type (ignoring
> that there has to be single url in default type)  but we cannot bring
> failover type into that. We can say that the first element in the array is
> the default url and others are failover endpoints. As I think it won't be
> convenient but still possible since we do not allow user to edit the file.
> WDYT?
>
> Thank you,
> Viraj
>
> On Thu, Mar 21, 2019 at 3:30 PM Viraj Gamage  wrote:
>
>> Hi Pubudu,
>>
>> This is a sample endpoint configuration generated by publisher API for
>> failover type. In that case, There is a single URL, and for failover
>> endpoints, there is an array.
>> Shouldn't that be the case, when it comes to failover type?
>>
>> ---
>> production_endpoints:
>>   url: https://localhost:9443/am/sample/pizzashack/v1/api/
>>   endpoint_type: http
>>   template_not_supported: false
>> sandbox_endpoints:
>>   url: https://localhost:9443/am/sample/pizzashack/v1/api/
>>   endpoint_type: http
>>   template_not_supported: false
>> endpoint_type: failover
>> production_failovers:
>> - url: http://api.worldbank.org
>>   endpoint_type: http
>>   template_not_supported: false
>>
>> Thank you,
>> Viraj
>>
>>
>> On Thu, Mar 21, 2019 at 3:17 PM Pubudu Gunatilaka 
>> wrote:
>>
>>> Hi Viraj,
>>>
>>> For endpoints, we should have a generic endpoint configuration as
>>> follows.
>>>
>>> For Load balancing:
>>>  type: "load_balance"
>>>   endpoints:
>>> - ""
>>> - ""
>>>
>>> For fail over:
>>>  type: "fail over"
>>>   endpoints:
>>> - ""
>>> - ""
>>>
>>>
>>> For default case:
>>>  type: "default"
>>>   endpoints:
>>> - ""
>>>
>>> Thank you!
>>> --
>>> *Pubudu Gunatilaka*
>>> Committer and PMC Member - Apache Stratos
>>> Associate Technical Lead
>>> WSO2, Inc.: http://wso2.com
>>> mobile : +94774078049 <%2B94772207163>
>>>
>>>
>>
>> --
>> *Viraj Salaka Gamage* | Software Engineer | WSO2 Inc.
>> +94 710 618 178
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> *Viraj Salaka Gamage* | Software Engineer | WSO2 Inc.
> +94 710 618 178
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
>


-- 
*Viraj Salaka Gamage* | Software Engineer | WSO2 Inc.
+94 710 618 178
GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM - Microgateway] Restructuring the Microgateway Project Folder Structure and Command Execution to Support Multiple APIs

[Pubudu Gunatilaka]

Hi Viraj,

For endpoints, we should have a generic endpoint configuration as follows.

For Load balancing:
 type: "load_balance"
  endpoints:
- ""
- ""

For fail over:
 type: "fail over"
  endpoints:
- ""
- ""


For default case:
 type: "default"
  endpoints:
- ""

Thank you!
-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Associate Technical Lead
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM - Microgateway] Restructuring the Microgateway Project Folder Structure and Command Execution to Support Multiple APIs

[Viraj Gamage]

Hi all,

>From the commands mentioned above,  setup command and build command will be
implemented in the newly proposed way as a start. For setup command, it
needs to be compatible for OpenAPI spec 2.0 as well as 3.0. Therefore we
take basepath as a command line argument when the OpenAPI version is 3.0.
Since the previous email contains a large amount of information, I will
repeat the *same information as in the previous email* which is only
relevant to setup and build commands.

   -  *micro-gw setup *
  - Project Structure will be created under the provided project name



   -
*micro-gw setup  -oa  -e  -b
*
  - In this case, the user has to provide the basePath if the OpenAPI
  spec is 3.0 or OpenAPI spec is 2.0 and basePath is not included.
  EndpointConfig is the global endpoint for the API. No ballerina code
  generation happens during the execution of this command. We create the
  folder structure and copy the swagger file into the relevant
directory. In
  the meantime, we will be updating the routes.yaml with global
  configuration. basePath will be saved in the routes.yaml file.
  - API_ID also will be generated using the hash value of
  “API_name:API_version” concatenated string. And the folder in which the
  swagger is saved will be named after that API_ID.
  - routes file will be updated with the basepath variable and the API
  level endpoint under the generated API_ID.



   - *micro-gw set project *
  - Since there can be so many projects, the user can specify the
  project he is currently working on so that he does not have to mention
  project name for each and every command repeatedly.



   - *micro-gw build*
  - This will generate the ballerina code, compile the ballerina code
  and after all, we can launch the project.

Thank you,
Viraj

-- 
*Viraj Salaka Gamage* | Software Engineer | WSO2 Inc.
+94 710 618 178
GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture