Re: [Architecture] [Intern Project] Integrating API gateway with AWS Lambda

[Chanaka Jayasena]

Also +1 to disable both Endpoints section and Resources while enabling
the LAMBDA section as you suggested. Wizard is something you can do
optionally. But you can reuse the components from Resource and Endpoints to
build the LAMDA component.

thanks,
Chanaka

On Fri, Aug 30, 2019 at 12:07 PM Chanaka Jayasena  wrote:

> I would suggest to add them separately and provide them a wizard to set
> AWS Lambda starting from the BIG overview page.
>
> The wizard will take the user through necessary steps and guide him
> through the different sections.
>
> With old UI tech, it's difficult to do something like this without
> duplicating the code hear and there. But now we can reuse the components in
> different sections and build a wizard out of them just to make the UX nice.
>
> We have done a similar thing with subscriptions in Store. It guides the
> user up to key generation but the application creation subscriptions and
> key generation are still keeps it's own location on the content tree. You
> can get more info from Dushan. He has nicely architecture the
> implementation of the same in store.
>
> thanks,
> Chanaka
>
> On Fri, Aug 30, 2019 at 11:46 AM Binod Karunanayake 
> wrote:
>
>> Hi all,
>>
>> So far, I have developed the code for creating apis to invoke Lambda
>> functions through REST API. *Still the above issue (set ByteBuffer
>> response to response path directly) is not resolved*. However, I'm
>> planning to start developing UI for this feature. Before that, I want to
>> clarify some things I noticed with the suggested UI.
>>
>> As we discussed in the design review, following widget will be added to
>> ENDPOINTS section.
>>
>> [image: image.png]
>> But I have some UX issues adding this kind of widget to ENDPOINTS page in
>> APIM 3.0.
>>
>> 1. A typical user will confuse by seeing resources in ENDPOINTS section.
>> 2. What will happen to RESOURCES section (whether it has to be disabled
>> after he selected the endpoint type as AWS Lambda)?
>> 3. What if the user adds resources first and then goes to ENDPOINTS
>> section to set AWS LAMBDA?
>>
>> To outcome these problems one can suggest to add AWS user role details
>> (access key & secret key) in ENDPOINTS section and map resources to ARNs in
>> RESOURCES section which raise following issues.
>>
>> 1. User has to first selects the endpoint type as AWS LAMBDA before set
>> the resources.
>> 2. Have to add optional interface for mapping ARNs in RESOURCES section.
>>
>> I'm suggesting to add separate section for LAMBDA configuration which
>> will disable ENDPOINTS and RESOURCES sections when an user enables LAMBDA
>> functions.
>>
>> [image: image.png]
>> What will be the best way to add this feature in APIM-Publisher?
>>
>>
>> On Tue, Aug 6, 2019 at 5:52 PM Binod Karunanayake  wrote:
>>
>>> Hi all,
>>>
>>> I'm doing the above project which is a new feature in WSO2 API-M to
>>> invoke AWS Lambda functions through WSO2 API gateway. You can find the
>>> detailed document attached below.
>>>
>>> There will be no backend endpoints for APIs. Instead, an API invokes
>>> Lambda functions as shown below.
>>> [image: 1*ucaFQnPaYgniRfOHbBpgwA.png]
>>> Calling Lambda is done by a class mediator. However, Lambda response is
>>> a *byteBuffer* which have to be set to the *messageContext*. I'm
>>> looking for a solution to set the Lambda response to messageContext without
>>> converting it to *String*.
>>>
>>> Best Regards.
>>>
>>> --
>>> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
>>> (m) +94716611642 | (e) bi...@wso2.com
>>> [image: http://wso2.com/signature] 
>>>
>>
>>
>> --
>> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
>> (m) +94716611642 | (e) bi...@wso2.com
>> [image: http://wso2.com/signature] 
>>
>
>
> --
> *Chanaka Jayasena* | Technical Lead | WSO2 Inc.
> (m) +94 77 44 64 00 6 | (w) 0112 145 345 | (e) chan...@wso2.com
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
>


-- 
*Chanaka Jayasena* | Technical Lead | WSO2 Inc.
(m) +94 77 44 64 00 6 | (w) 0112 145 345 | (e) chan...@wso2.com
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] [Intern Project] Integrating API gateway with AWS Lambda

[Chanaka Jayasena]

I would suggest to add them separately and provide them a wizard to set AWS
Lambda starting from the BIG overview page.

The wizard will take the user through necessary steps and guide him through
the different sections.

With old UI tech, it's difficult to do something like this without
duplicating the code hear and there. But now we can reuse the components in
different sections and build a wizard out of them just to make the UX nice.

We have done a similar thing with subscriptions in Store. It guides the
user up to key generation but the application creation subscriptions and
key generation are still keeps it's own location on the content tree. You
can get more info from Dushan. He has nicely architecture the
implementation of the same in store.

thanks,
Chanaka

On Fri, Aug 30, 2019 at 11:46 AM Binod Karunanayake  wrote:

> Hi all,
>
> So far, I have developed the code for creating apis to invoke Lambda
> functions through REST API. *Still the above issue (set ByteBuffer
> response to response path directly) is not resolved*. However, I'm
> planning to start developing UI for this feature. Before that, I want to
> clarify some things I noticed with the suggested UI.
>
> As we discussed in the design review, following widget will be added to
> ENDPOINTS section.
>
> [image: image.png]
> But I have some UX issues adding this kind of widget to ENDPOINTS page in
> APIM 3.0.
>
> 1. A typical user will confuse by seeing resources in ENDPOINTS section.
> 2. What will happen to RESOURCES section (whether it has to be disabled
> after he selected the endpoint type as AWS Lambda)?
> 3. What if the user adds resources first and then goes to ENDPOINTS
> section to set AWS LAMBDA?
>
> To outcome these problems one can suggest to add AWS user role details
> (access key & secret key) in ENDPOINTS section and map resources to ARNs in
> RESOURCES section which raise following issues.
>
> 1. User has to first selects the endpoint type as AWS LAMBDA before set
> the resources.
> 2. Have to add optional interface for mapping ARNs in RESOURCES section.
>
> I'm suggesting to add separate section for LAMBDA configuration which will
> disable ENDPOINTS and RESOURCES sections when an user enables LAMBDA
> functions.
>
> [image: image.png]
> What will be the best way to add this feature in APIM-Publisher?
>
>
> On Tue, Aug 6, 2019 at 5:52 PM Binod Karunanayake  wrote:
>
>> Hi all,
>>
>> I'm doing the above project which is a new feature in WSO2 API-M to
>> invoke AWS Lambda functions through WSO2 API gateway. You can find the
>> detailed document attached below.
>>
>> There will be no backend endpoints for APIs. Instead, an API invokes
>> Lambda functions as shown below.
>> [image: 1*ucaFQnPaYgniRfOHbBpgwA.png]
>> Calling Lambda is done by a class mediator. However, Lambda response is a
>> *byteBuffer* which have to be set to the *messageContext*. I'm looking
>> for a solution to set the Lambda response to messageContext without
>> converting it to *String*.
>>
>> Best Regards.
>>
>> --
>> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
>> (m) +94716611642 | (e) bi...@wso2.com
>> [image: http://wso2.com/signature] 
>>
>
>
> --
> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
> (m) +94716611642 | (e) bi...@wso2.com
> [image: http://wso2.com/signature] 
>


-- 
*Chanaka Jayasena* | Technical Lead | WSO2 Inc.
(m) +94 77 44 64 00 6 | (w) 0112 145 345 | (e) chan...@wso2.com
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] [Intern Project] Integrating API gateway with AWS Lambda

[Binod Karunanayake]

Hi all,

So far, I have developed the code for creating apis to invoke Lambda
functions through REST API. *Still the above issue (set ByteBuffer response
to response path directly) is not resolved*. However, I'm planning to start
developing UI for this feature. Before that, I want to clarify some things
I noticed with the suggested UI.

As we discussed in the design review, following widget will be added to
ENDPOINTS section.

[image: image.png]
But I have some UX issues adding this kind of widget to ENDPOINTS page in
APIM 3.0.

1. A typical user will confuse by seeing resources in ENDPOINTS section.
2. What will happen to RESOURCES section (whether it has to be disabled
after he selected the endpoint type as AWS Lambda)?
3. What if the user adds resources first and then goes to ENDPOINTS section
to set AWS LAMBDA?

To outcome these problems one can suggest to add AWS user role details
(access key & secret key) in ENDPOINTS section and map resources to ARNs in
RESOURCES section which raise following issues.

1. User has to first selects the endpoint type as AWS LAMBDA before set the
resources.
2. Have to add optional interface for mapping ARNs in RESOURCES section.

I'm suggesting to add separate section for LAMBDA configuration which will
disable ENDPOINTS and RESOURCES sections when an user enables LAMBDA
functions.

[image: image.png]
What will be the best way to add this feature in APIM-Publisher?


On Tue, Aug 6, 2019 at 5:52 PM Binod Karunanayake  wrote:

> Hi all,
>
> I'm doing the above project which is a new feature in WSO2 API-M to invoke
> AWS Lambda functions through WSO2 API gateway. You can find the detailed
> document attached below.
>
> There will be no backend endpoints for APIs. Instead, an API invokes
> Lambda functions as shown below.
> [image: 1*ucaFQnPaYgniRfOHbBpgwA.png]
> Calling Lambda is done by a class mediator. However, Lambda response is a
> *byteBuffer* which have to be set to the *messageContext*. I'm looking
> for a solution to set the Lambda response to messageContext without
> converting it to *String*.
>
> Best Regards.
>
> --
> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
> (m) +94716611642 | (e) bi...@wso2.com
> [image: http://wso2.com/signature] 
>


-- 
*Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
(m) +94716611642 | (e) bi...@wso2.com
[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM 3.0.0 Mediation Policy REST API

[Dushan Silva]

Hi ishara,
Whats the purpose of saving the method it was received (sourceType) ?
Correct me if i'm wrong but I feel like we do not need it as I do not see
that value being useful.

inline editor in the future to edit the mediation policies withing the
publisher portal.

Even for this we do not need to save the sourceType right ?

On Fri, Aug 30, 2019 at 9:17 AM Malintha Amarasinghe 
wrote:

> Few inline comments:
>
> On Fri, Aug 30, 2019 at 6:04 AM Ishara Cooray  wrote:
>
>> Hi,
>> In APIM 3.0.0 Publisher rest api , we have introduced separate two APIs
>> to retrieve mediation policy content as files. Each for API specific custom
>> mediation policy content and for global mediation policy content.
>>
>> Previously, mediation policy content was in the same Mediation resource
>> as below.
>>
>> #-
>> # The Mediation resource
>> #-
>> Mediation:
>>   title: Mediation
>>   required:
>> - name
>> - type
>> - config
>>   properties:
>> id:
>>   type: string
>>   example: 01234567-0123-0123-0123-012345678901
>> name:
>>   type: string
>>   example: json_fault.xml
>>
>> type:
>>   type: string
>>   enum:
>> - in
>> - out
>> - fault
>>   example: in
>> config:
>>   type: string
>>   example: 'http://ws.apache.org/ns/synapse"; 
>> name="log_in_message">
>> 
>> > value="IN_MESSAGE_21133232"/>
>> 
>> '
>>
>> *In APIM 3.0.0* this is changed to,
>> #-
>> # The Mediation resource
>> #-
>> Mediation:
>>   title: Mediation
>>   required:
>>   - name
>>   - type
>>   properties:
>> id:
>>   type: string
>>   example: 01234567-0123-0123-0123-012345678901
>> name:
>>   type: string
>>   example: json_fault.xml
>>
>> I guess we do not need the extension here? We can use the name only.
>
>> type:
>>   type: string
>>   enum:
>>   - in
>>   - out
>>   - fault
>>   example: in
>> sourceType:
>>   type: string
>>   enum:
>>   - FILE
>>   - INLINE
>>
>> ** config property has been removed and a new property sourceType is 
>> introduced.
>>
>> sourceType will decide whether the mediation policy content is received as a 
>> file or inline content.
>> Because we are planing to give an inline editor in the future to edit the 
>> mediation policies withing the publisher portal.
>>
>> So to get a content of a mediation policy we have introduced below two rest 
>> apis.
>>
>> ###
>> # The "Individual API specific mediation sequence content" resource
>> ###
>> /apis/{apiId}/mediation-policies/{mediationPolicyId}/content:
>>
>>   #---
>>   # Retrieve a particular API specific mediation sequence content
>>   #---
>>   get:
>> security:
>> - OAuth2Security:
>>   - apim:api_view
>> x-examples:
>>   $ref: docs/examples/apis/apis_id_mediationpolicies_id_content_get.yaml
>> summary: Downloadt an API specific mediation policy
>>
>> Small typo.
>
>> description: |
>>   This operation can be used to download a particular API specific 
>> mediation policy.
>> parameters:
>> - $ref: '#/parameters/apiId'
>> - $ref: '#/parameters/mediationPolicyId'
>> - $ref: '#/parameters/If-None-Match'
>> tags:
>> - API Mediation Policy
>>
>> Shall we use: "API Mediation Policies" (plural format as other existing
> tags).
>
>>
>>
>> responses:
>>   200:
>> description: |
>>   OK.
>>   Mediation policy returned.
>> headers:
>>   Content-Type:
>> description: |
>>   The content type of the body.
>> type: string
>>   ETag:
>> description: |
>>   Entity Tag of the response resource.
>>   Used by caches, or in conditional requests (Will be supported 
>> in future).
>> type: string
>>   Last-Modified:
>> description: |
>>   Date and time the resource has been modifed the last time.
>>   Used by caches, or in conditional requests (Will be supported 
>> in future).
>> type: string
>>   304:
>> description: |
>>   Not Modified.
>>   Empty body because the client has already the latest version of 
>> the requested resource (Will be supported in future).
>>   404:
>> description: |
>>   Not Found.
>>   Requested file does not exist.
>> schema:
>>   $ref: '#/definitions/Error'
>>

Re: [Architecture] APIM 3.0.0 Mediation Policy REST API

[Malintha Amarasinghe]

Few inline comments:

On Fri, Aug 30, 2019 at 6:04 AM Ishara Cooray  wrote:

> Hi,
> In APIM 3.0.0 Publisher rest api , we have introduced separate two APIs to
> retrieve mediation policy content as files. Each for API specific custom
> mediation policy content and for global mediation policy content.
>
> Previously, mediation policy content was in the same Mediation resource as
> below.
>
> #-
> # The Mediation resource
> #-
> Mediation:
>   title: Mediation
>   required:
> - name
> - type
> - config
>   properties:
> id:
>   type: string
>   example: 01234567-0123-0123-0123-012345678901
> name:
>   type: string
>   example: json_fault.xml
>
> type:
>   type: string
>   enum:
> - in
> - out
> - fault
>   example: in
> config:
>   type: string
>   example: 'http://ws.apache.org/ns/synapse"; 
> name="log_in_message">
> 
>  value="IN_MESSAGE_21133232"/>
> 
> '
>
> *In APIM 3.0.0* this is changed to,
> #-
> # The Mediation resource
> #-
> Mediation:
>   title: Mediation
>   required:
>   - name
>   - type
>   properties:
> id:
>   type: string
>   example: 01234567-0123-0123-0123-012345678901
> name:
>   type: string
>   example: json_fault.xml
>
> I guess we do not need the extension here? We can use the name only.

> type:
>   type: string
>   enum:
>   - in
>   - out
>   - fault
>   example: in
> sourceType:
>   type: string
>   enum:
>   - FILE
>   - INLINE
>
> ** config property has been removed and a new property sourceType is 
> introduced.
>
> sourceType will decide whether the mediation policy content is received as a 
> file or inline content.
> Because we are planing to give an inline editor in the future to edit the 
> mediation policies withing the publisher portal.
>
> So to get a content of a mediation policy we have introduced below two rest 
> apis.
>
> ###
> # The "Individual API specific mediation sequence content" resource
> ###
> /apis/{apiId}/mediation-policies/{mediationPolicyId}/content:
>
>   #---
>   # Retrieve a particular API specific mediation sequence content
>   #---
>   get:
> security:
> - OAuth2Security:
>   - apim:api_view
> x-examples:
>   $ref: docs/examples/apis/apis_id_mediationpolicies_id_content_get.yaml
> summary: Downloadt an API specific mediation policy
>
> Small typo.

> description: |
>   This operation can be used to download a particular API specific 
> mediation policy.
> parameters:
> - $ref: '#/parameters/apiId'
> - $ref: '#/parameters/mediationPolicyId'
> - $ref: '#/parameters/If-None-Match'
> tags:
> - API Mediation Policy
>
> Shall we use: "API Mediation Policies" (plural format as other existing
tags).

>
>
> responses:
>   200:
> description: |
>   OK.
>   Mediation policy returned.
> headers:
>   Content-Type:
> description: |
>   The content type of the body.
> type: string
>   ETag:
> description: |
>   Entity Tag of the response resource.
>   Used by caches, or in conditional requests (Will be supported 
> in future).
> type: string
>   Last-Modified:
> description: |
>   Date and time the resource has been modifed the last time.
>   Used by caches, or in conditional requests (Will be supported 
> in future).
> type: string
>   304:
> description: |
>   Not Modified.
>   Empty body because the client has already the latest version of the 
> requested resource (Will be supported in future).
>   404:
> description: |
>   Not Found.
>   Requested file does not exist.
> schema:
>   $ref: '#/definitions/Error'
>
>
> ###
> # The "Individual Global mediation policy content" resource
> ###
> /mediation-policies/{mediationPolicyId}/content:
>
>   #---
>   # Retrieve a particular Global mediation sequence content
>   #---
>   get:
> security:
> - OAuth2Security:
>   - apim:api_view
> summary: Downloa

Re: [Architecture] APIM 3.0.0 Mediation Policy REST API

[Malintha Amarasinghe]

Hi Ishara

On Fri, Aug 30, 2019 at 6:04 AM Ishara Cooray  wrote:

> Hi,
> In APIM 3.0.0 Publisher rest api , we have introduced separate two APIs to
> retrieve mediation policy content as files. Each for API specific custom
> mediation policy content and for global mediation policy content.
>
> Previously, mediation policy content was in the same Mediation resource as
> below.
>
> #-
> # The Mediation resource
> #-
> Mediation:
>   title: Mediation
>   required:
> - name
> - type
> - config
>   properties:
> id:
>   type: string
>   example: 01234567-0123-0123-0123-012345678901
> name:
>   type: string
>   example: json_fault.xml
> type:
>   type: string
>   enum:
> - in
> - out
> - fault
>   example: in
> config:
>   type: string
>   example: 'http://ws.apache.org/ns/synapse"; 
> name="log_in_message">
> 
>  value="IN_MESSAGE_21133232"/>
> 
> '
>
> *In APIM 3.0.0* this is changed to,
> #-
> # The Mediation resource
> #-
> Mediation:
>   title: Mediation
>   required:
>   - name
>   - type
>   properties:
> id:
>   type: string
>   example: 01234567-0123-0123-0123-012345678901
> name:
>   type: string
>   example: json_fault.xml
> type:
>   type: string
>   enum:
>   - in
>   - out
>   - fault
>   example: in
> sourceType:
>   type: string
>   enum:
>   - FILE
>   - INLINE
>
> ** config property has been removed and a new property sourceType is 
> introduced.
>
> sourceType will decide whether the mediation policy content is received as a 
> file or inline content.
> Because we are planing to give an inline editor in the future to edit the 
> mediation policies withing the publisher portal.
>
>
+1 for removing `config` from the payload.
But I doubt we still need, sourceType. We use sourceType: FILE/INLINE for
documents because we allow people to upload PDF etc which are binary and
not editable in a text editor. But for mediation policies, it is always
text so we can even allow people to update uploaded files as well via the
inline editor.

Thanks!

>
> So to get a content of a mediation policy we have introduced below two rest 
> apis.
>
> ###
> # The "Individual API specific mediation sequence content" resource
> ###
> /apis/{apiId}/mediation-policies/{mediationPolicyId}/content:
>
>   #---
>   # Retrieve a particular API specific mediation sequence content
>   #---
>   get:
> security:
> - OAuth2Security:
>   - apim:api_view
> x-examples:
>   $ref: docs/examples/apis/apis_id_mediationpolicies_id_content_get.yaml
> summary: Downloadt an API specific mediation policy
> description: |
>   This operation can be used to download a particular API specific 
> mediation policy.
> parameters:
> - $ref: '#/parameters/apiId'
> - $ref: '#/parameters/mediationPolicyId'
> - $ref: '#/parameters/If-None-Match'
> tags:
> - API Mediation Policy
> responses:
>   200:
> description: |
>   OK.
>   Mediation policy returned.
> headers:
>   Content-Type:
> description: |
>   The content type of the body.
> type: string
>   ETag:
> description: |
>   Entity Tag of the response resource.
>   Used by caches, or in conditional requests (Will be supported 
> in future).
> type: string
>   Last-Modified:
> description: |
>   Date and time the resource has been modifed the last time.
>   Used by caches, or in conditional requests (Will be supported 
> in future).
> type: string
>   304:
> description: |
>   Not Modified.
>   Empty body because the client has already the latest version of the 
> requested resource (Will be supported in future).
>   404:
> description: |
>   Not Found.
>   Requested file does not exist.
> schema:
>   $ref: '#/definitions/Error'
>
>
> ###
> # The "Individual Global mediation policy content" resource
> ###
> /mediation-policies/{mediationPolicyId}/content:
>
>   #---
>   # Retrieve a particular Global mediation sequence

[Architecture] APIM 3.0.0 Mediation Policy REST API

[Ishara Cooray]

Hi,
In APIM 3.0.0 Publisher rest api , we have introduced separate two APIs to
retrieve mediation policy content as files. Each for API specific custom
mediation policy content and for global mediation policy content.

Previously, mediation policy content was in the same Mediation resource as
below.

#-
# The Mediation resource
#-
Mediation:
  title: Mediation
  required:
- name
- type
- config
  properties:
id:
  type: string
  example: 01234567-0123-0123-0123-012345678901
name:
  type: string
  example: json_fault.xml
type:
  type: string
  enum:
- in
- out
- fault
  example: in
config:
  type: string
  example: 'http://ws.apache.org/ns/synapse";
name="log_in_message">



'

*In APIM 3.0.0* this is changed to,
#-
# The Mediation resource
#-
Mediation:
  title: Mediation
  required:
  - name
  - type
  properties:
id:
  type: string
  example: 01234567-0123-0123-0123-012345678901
name:
  type: string
  example: json_fault.xml
type:
  type: string
  enum:
  - in
  - out
  - fault
  example: in
sourceType:
  type: string
  enum:
  - FILE
  - INLINE

** config property has been removed and a new property sourceType is introduced.

sourceType will decide whether the mediation policy content is
received as a file or inline content.
Because we are planing to give an inline editor in the future to edit
the mediation policies withing the publisher portal.

So to get a content of a mediation policy we have introduced below two
rest apis.

###
# The "Individual API specific mediation sequence content" resource
###
/apis/{apiId}/mediation-policies/{mediationPolicyId}/content:

  #---
  # Retrieve a particular API specific mediation sequence content
  #---
  get:
security:
- OAuth2Security:
  - apim:api_view
x-examples:
  $ref: docs/examples/apis/apis_id_mediationpolicies_id_content_get.yaml
summary: Downloadt an API specific mediation policy
description: |
  This operation can be used to download a particular API specific
mediation policy.
parameters:
- $ref: '#/parameters/apiId'
- $ref: '#/parameters/mediationPolicyId'
- $ref: '#/parameters/If-None-Match'
tags:
- API Mediation Policy
responses:
  200:
description: |
  OK.
  Mediation policy returned.
headers:
  Content-Type:
description: |
  The content type of the body.
type: string
  ETag:
description: |
  Entity Tag of the response resource.
  Used by caches, or in conditional requests (Will be
supported in future).
type: string
  Last-Modified:
description: |
  Date and time the resource has been modifed the last time.
  Used by caches, or in conditional requests (Will be
supported in future).
type: string
  304:
description: |
  Not Modified.
  Empty body because the client has already the latest version
of the requested resource (Will be supported in future).
  404:
description: |
  Not Found.
  Requested file does not exist.
schema:
  $ref: '#/definitions/Error'


###
# The "Individual Global mediation policy content" resource
###
/mediation-policies/{mediationPolicyId}/content:

  #---
  # Retrieve a particular Global mediation sequence content
  #---
  get:
security:
- OAuth2Security:
  - apim:api_view
summary: Downloadt specific global mediation policy
description: |
  This operation can be used to download a particular global
mediation policy.
parameters:
- $ref: '#/parameters/mediationPolicyId'
- $ref: '#/parameters/If-None-Match'
tags:
- Global Mediation Policy

Thanks & Regards,

Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Supporting Email or Mobile as the Preferred Communication Channel for Users

[Sominda Gamage]

Hi all,

I have implemented a new set of APIs to support account recovery flow via a
user preferred communication channel. Please refer to the mail [1] for more
information about the implementation.
Thank you.

[1] - New APIs to support user account recovery via user preferred channel
for Identity Server

Regards,
Sominda

On Tue, Aug 13, 2019 at 9:55 AM Sominda Gamage  wrote:

> Hi all,
>
> Please find the solution proposal of implementing a preferred channel for
> user self registration flow.
>
> User self registration
> *User Narrative*
>
>1.
>
>When a user self registrates, the user
>1.
>
>   Has to provide either a mobile number or an email address or both.
>   2.
>
>   Can provide a preferred communication channel as Email or SMS.
>   2.
>
>Then the user will get recovery notifications based on the provided
>communication channels.
>
>
>-
>
>If the channel is email: navigate to the email and click the
>verification link to verify the user account.
>-
>
>If the channel is SMS: provide the received OTP during the self
>registration phase and confirm the user account.
>
> *Solution*
>
>-
>
>In a self registration request following claims are required for the
>server to initiate an account verification request.
>-
>
>   Either mobile number or email address claims or both claims (At
>   least one claim should be in the request).
>   -
>
>  Mobile claim: http://wso2.org/claims/mobile
>  -
>
>  Email claim: http://wso2.org/claims/emailaddress
>  -
>
>If any of the above channels are verified external to the Identity
>Server, Phone Verified and Email Verified claims needs to be in the
>request with value being set to TRUE.
>-
>
>   Eg: If the mobile is already verified, then Phone verified request
>   needs to be in the self registration request with value being set to 
> TRUE.
>   -
>
>   Phone Verified: http://wso2.org/claims/identity/mobileVerified
>   -
>
>   Email Verified: http://wso2.org/claims/identity/emailVerified
>
>
>-
>
>A claim with users preference can be included in the request.
>-
>
>   This claim is optional but it is recommended to send the claim with
>   the request).
>   -
>
>   The claim should be as follows.
>   -
>
>  Preferred Channel:
>  http://wso2.org/claims/identity/preferredChannel
>  -
>
>User Self Registration should be configured for the respective tenant
>(Refer to the User Self Registration Configurations in the appendix).
>-
>
>Once the server receives a self registration request, server will send
>notifications to the user by resolving the communication channel
>internally. Notification channel resolution will be as follows.
>
> Communication Channel Selection Criteria
>
>1.
>
>If the user has only provided email address or mobile number as the
>communication channel and,
>1.
>
>   Not specified the preferred channel: communication will happen via
>   the given channel in the request.
>
> (Eg: If only the mobile is provided, mobile will be considered as the
> preferred channel.
>
>1.
>
>Specified the preferred channel:
>1.
>
>   Preferred channel matches the given claim: communication via
>   preferred channel
>
> (Eg: Preferred channel: SMS and given a mobile number)
>
>1.
>
>Preferred channel does not match the claim: 400 ERROR
>
> (Eg: Preferred channel: SMS but not given a mobile number)
>
> Note: This means that there is a claim bound with a specific
> communication channel
>
> Channel: EMAIL -> Claim: http://wso2.org/claims/emailaddress
>
> Channel: SMS -> Claim: http://wso2.org/claims/mobile
>
>1.
>
>If the user has provided both email and mobile as communication
>channels.
>1.
>
>   Specified the preferred channel: communication via preferred channel
>   2.
>
>   Not specified the preferred channel: communication via the server
>   default channel.
>
>
>-
>
>Once the communication channel is resolved, an event will be
>triggered. The event name would be in the following format.
>-
>
>   Event name: TRIGGER__NOTIFICATION
>   -
>
>   Communication channels supported with this scope:
>   -
>
>  SMS
>  -
>
>  EMAIL
>  -
>
>Once the event is triggered notification handlers will send
>notifications to the user.
>
> *Deliverables*
>
> We have planned to deliver the solution according to the following phases.
>
>1.
>
>Phase 1
>
>Support mobile and email channels for Self registration APIs.
>
>
>1.
>
>Phase 2
>
> Support mobile and email channels for self registration via SCIM/ME
> endpoint.
>
>1.
>
>Phase 3
>
> Provide UI support for account confirmation via mobile and email channels.
> Current Status
>
> Currently, I'm in phase 1, implementing APIs to su

[Architecture] WSO2 Identity Server REST API Error Response Standardization

[Sominda Gamage]

Hi all,

Currently, the REST APIs of Identity Server have different error codes such
as (20018, 20048, etc.). The error codes in this format have less
information regarding the cause or where it has occurred.

Therefore, we would like to maintain the error codes which are used in our
REST APIs in one commonplace. Currently, we are standardizing error codes
along with their details and this is still a work in progress.

According to this effort, sample error code will look like “
-

Eg: CQM-10005

The Prefix (first part) indicates the component. In this case, CQM
indicates Challenge Questions Management.
The error-identifier-number (the second part of the error code) reflects
the numerical identifier for the error.

For the rest APIs, we have defined 2 types of codes for both user and
server APIs.

   -

   Success codes: For successful operations
   -

   Error codes: For error scenarios
   -

  Client Errors
  -

  Server Errors



*Success Codes*

Despite the API type, all the success codes will start from 02000 onwards.
To maintain consistency, a zero will be added at the beginning.

Eg: USR-02001

The above Success Code indicates a successful User Self Registration.


*Error Codes*

With the introduction of API error standards, we wish to standardize the
error response from an API. Therefore, a sample API error response will be
as follows.

{

“code” : “some_error_code”,

“Message” : “some_error_message”,

“Description” : “some_error_description”,

“traceID” : “correlation_id”

}

A correlationId has been introduced to log the error and send with the
response


*User API errors*

User APIs has two types of errors.

   1.

   Client errors
   2.

   Server errors

*Client Errors in user APIs*

For client errors in user APIs, we have allocated the range starting from
100.

Eg: USR-100xx

*Server Errors in user APIs*

For server errors in user APIs, we have allocated the range starting from
100.

Eg: USR-150xx


*Server API Errors*

Server APIs has two types of errors.

   1.

   Client errors
   2.

   Server errors

*Client errors in server APIs*

For client errors in server APIs, we have allocated the range starting from
500.

Eg: USR-500xx

*Server Errors in server APIs*

For server errors in server APIs, we have allocated the range starting from
550.

Eg: USR-550xx


This will be the new standardization for Rest API Success and Error
responses.


Thanks & Regards,

Sominda.

-- 
*Sominda Gamage* | Software Engineer| WSO2 Inc. 
(M)+94 719873902 | (E) somi...@wso2.com

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