Re: [Architecture] [ESB] Fetching message store parameters from the registry

[Sameera Gunarathne]

Hi Thishani,

Yes, the idea is to give both options to the user so that the parameter
values can be defined inline or using registry keys.

Regards,

On Wed, May 23, 2018 at 9:45 AM, Thishani Lucas  wrote:

> Hi Sameera,
>
> Will it be possible that the user can select between whether he wants to
> give the params as hard-coded values or using the registry keys?
>
> Thanks.
>
> On Tue, May 22, 2018 at 6:39 PM, Sameera Gunarathne 
> wrote:
>
>> Hi,
>>
>> I'm working on the $subject and the user story can be referred in [1].
>> Currently, users can define inline parameter definitions when configuring
>> message stores in ESB. When implementing the $subject users will be able to
>> define the parameter values as a registry keys like the following
>> configuration.
>>
>> 
>> http://ws.apache.org/ns/synapse;
>>   class="org.apache.synapse.mess
>> age.store.impl.rabbitmq.RabbitMQStore"
>>   name="RabbitMS">
>>> *key="conf:/repository/esb/esb-configurations/host_name"* />
>>false> parameter>
>>5672
>> 
>>
>> [1]- https://docs.google.com/document/d/1GdeQjNmDWuZQEcraqCG
>> ymHokJl63gNsycCtdH6Ho7Uk/edit?usp=sharing
>>
>> Thanks and Regards,
>> --
>> Sameera Gunarathne
>> Software Engineer, WSO2 Inc. http://wso2.com
>> 
>> Email: samee...@wso2.com
>> Mobile: +94714155561
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Regards,
>
> *Thishani Lucas*
> *Software Engineer*
> *WSO2 Lanka (Private) Limited**: http://wso2.com *
> *lean.enterprise.middle-ware*
>
> *Tel: +94 77 2556931 *
>
> *LinkedIn: https://www.linkedin.com/in/thishani-lucas/
> *
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sameera Gunarathne
Software Engineer, WSO2 Inc. http://wso2.com

Email: samee...@wso2.com
Mobile: +94714155561
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Handling custom claims when generating JWT token using JWT grant type

[Megala Uthayakumar]

Hi All,

I am working on $subject for IS 5.5.0.

When handling custom claims, we do have two options.

   1. Handling custom claims as we have handled it in the
   SAML2BearerGrantHandler.
  - Current SAML2BearerGrantHandler converts the claims coming from IDP
  to local claims and then filter out oidc claims only, given that scope is
  given as openid.
  2. Handle relevant custom claims as it is when scope is not openid
   and if the scope is openid filter out the openid scopes as we do for
   SAML2BearerGrantHandler
  - If the scope is not openid, add all the custom claims with the
  access token.
  - If the scope is openid, follow the same approach followed by
  SAML2BearerGrantHandler.

I think option 2 is better way to handle this, becuase,

JWT do not restrict the collection of custom claims, hence if we go with
option 1, customer is expected to select one of the open id claims to get
his claims back in original incoming JWT.

Appreciate your input on this. What is the correct way to move forward?

Thanks.

Regards,
Megala

-- 
Megala Uthayakumar

Senior Software Engineer
Mobile : 0779967122
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [ESB] Fetching message store parameters from the registry

[Thishani Lucas]

Hi Sameera,

Will it be possible that the user can select between whether he wants to
give the params as hard-coded values or using the registry keys?

Thanks.

On Tue, May 22, 2018 at 6:39 PM, Sameera Gunarathne 
wrote:

> Hi,
>
> I'm working on the $subject and the user story can be referred in [1].
> Currently, users can define inline parameter definitions when configuring
> message stores in ESB. When implementing the $subject users will be able to
> define the parameter values as a registry keys like the following
> configuration.
>
> 
> http://ws.apache.org/ns/synapse;
>   class="org.apache.synapse.message.store.impl.rabbitmq.
> RabbitMQStore"
>   name="RabbitMS">
> *key="conf:/repository/esb/esb-configurations/host_name"* />
>
> false
>5672
> 
>
> [1]- https://docs.google.com/document/d/1GdeQjNmDWuZQEcraqCGymHokJl63g
> NsycCtdH6Ho7Uk/edit?usp=sharing
>
> Thanks and Regards,
> --
> Sameera Gunarathne
> Software Engineer, WSO2 Inc. http://wso2.com
> 
> Email: samee...@wso2.com
> Mobile: +94714155561
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Regards,

*Thishani Lucas*
*Software Engineer*
*WSO2 Lanka (Private) Limited**: http://wso2.com *
*lean.enterprise.middle-ware*

*Tel: +94 77 2556931 *

*LinkedIn: https://www.linkedin.com/in/thishani-lucas/
*


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

Re: [Architecture] Conditional authentication - functions

[Nilasini Thirunavukkarasu]

Hi Farasath,

On Tue, May 22, 2018 at 11:32 PM, Farasath Ahamed 
wrote:

>
>
> On Mon, May 21, 2018 at 6:27 PM, Nilasini Thirunavukkarasu <
> nilas...@wso2.com> wrote:
>
>> Hi,
>>
>> I am going to introduce following APIs for script-based conditional
>> authentication.
>>
>> 1. lockUserAccount(user)
>>
>>- locks the user account. Only the admin can unlock the account
>>
>> *Example:-  *If the user A has logged in from a different country, then
>> User A's account can be locked using the above function.
>>
>>
>> 2. enableUserAccount(user)
>>
>>- When the user account is in disable state admin can enable the user
>>account using the above function.
>>
>>
>> 3. getLocalUser(user,idp)
>>
> How about naming this function getAssociatedLocalUser(user, idp)? It gives
> a better indication of what the function is meant for IMO
>
+1

>
>>- Get the local user. If it is a federation login, check whether the
>>federated user is associated with a local user. If there is a user
>>association then return the associated local user, if not return null.
>>- Parameters:- user - federated user, idp - federated identity
>>provider
>>
>> *Example:-  *UserA has an association in IS with his Facebook account.
>> If the UserA logs in from facebook, his associated local account can be
>> retrieved using above function.
>>
>>
>> 4. associateUserAccount(localuser, fuser, fidp)
>>
>>- Associate the local user with the federated user.
>>- Parameters:- fuser - federated user, fidp - federated identity
>>provider
>>
>> *Example:- *If the user A has two accounts, an account in IS and an
>> account on Facebook. We can use above function with the
>> two-step authentication to associate those two accounts automatically.
>>
>>
>> Any suggestions would be appreciated.
>>
>> Thanks,
>> Nila.
>>
>>
>> --
>> Nilasini Thirunavukkarasu
>> Software Engineer - WSO2
>>
>> Email : nilas...@wso2.com
>> Mobile : +94775241823
>> Web : http://wso2.com/
>>
>>
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Farasath Ahamed
> Senior Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Nilasini Thirunavukkarasu
Software Engineer - WSO2

Email : nilas...@wso2.com
Mobile : +94775241823
Web : http://wso2.com/



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

Re: [Architecture] Conditional authentication - functions

[Farasath Ahamed]

On Mon, May 21, 2018 at 6:27 PM, Nilasini Thirunavukkarasu <
nilas...@wso2.com> wrote:

> Hi,
>
> I am going to introduce following APIs for script-based conditional
> authentication.
>
> 1. lockUserAccount(user)
>
>- locks the user account. Only the admin can unlock the account
>
> *Example:-  *If the user A has logged in from a different country, then
> User A's account can be locked using the above function.
>
>
> 2. enableUserAccount(user)
>
>- When the user account is in disable state admin can enable the user
>account using the above function.
>
>
> 3. getLocalUser(user,idp)
>
How about naming this function getAssociatedLocalUser(user, idp)? It gives
a better indication of what the function is meant for IMO


>
>- Get the local user. If it is a federation login, check whether the
>federated user is associated with a local user. If there is a user
>association then return the associated local user, if not return null.
>- Parameters:- user - federated user, idp - federated identity provider
>
> *Example:-  *UserA has an association in IS with his Facebook account. If
> the UserA logs in from facebook, his associated local account can be
> retrieved using above function.
>
>
> 4. associateUserAccount(localuser, fuser, fidp)
>
>- Associate the local user with the federated user.
>- Parameters:- fuser - federated user, fidp - federated identity
>provider
>
> *Example:- *If the user A has two accounts, an account in IS and an
> account on Facebook. We can use above function with the
> two-step authentication to associate those two accounts automatically.
>
>
> Any suggestions would be appreciated.
>
> Thanks,
> Nila.
>
>
> --
> Nilasini Thirunavukkarasu
> Software Engineer - WSO2
>
> Email : nilas...@wso2.com
> Mobile : +94775241823
> Web : http://wso2.com/
>
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Farasath Ahamed
Senior Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 

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

[Architecture] [ESB] Fetching message store parameters from the registry

[Sameera Gunarathne]

Hi,

I'm working on the $subject and the user story can be referred in [1].
Currently, users can define inline parameter definitions when configuring
message stores in ESB. When implementing the $subject users will be able to
define the parameter values as a registry keys like the following
configuration.


http://ws.apache.org/ns/synapse;

class="org.apache.synapse.message.store.impl.rabbitmq.RabbitMQStore"
  name="RabbitMS">
   
   false
   5672


[1]-
https://docs.google.com/document/d/1GdeQjNmDWuZQEcraqCGymHokJl63gNsycCtdH6Ho7Uk/edit?usp=sharing

Thanks and Regards,
-- 
Sameera Gunarathne
Software Engineer, WSO2 Inc. http://wso2.com

Email: samee...@wso2.com
Mobile: +94714155561
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][API-Manager gateway] REST API to Fetch API Details to APIM-Gateway

[Malintha Amarasinghe]

It would be superb if we are supporting the "expand" parameter without any
constraints. But now this becomes a general parameter, we may need to test
with other inputs combinations as well. eg: expand with name and pagination
limits.

Thanks!

On Tue, May 22, 2018 at 1:30 PM Sachini De Silva  wrote:

> Hi,
>
> As per the discussion with team, we are going to send full APIDeatils
> whenever get /apis is invoked with expand parameter set as true. In short
> expand parameter would not be bound to just api labels feature but will
> have the implied meaning in the context. (i.e whatever the resultant API
> list will be returned with full details)
>
> Thanks,
> Sachini
>
> On Tue, May 22, 2018 at 12:09 PM, Malintha Amarasinghe  > wrote:
>
>>
>>
>> On Tue, May 22, 2018 at 11:25 AM Sachini De Silva 
>> wrote:
>>
>>> Hi all,
>>>
>>> This is to clarify a doubt.
>>>
>>> What should be done when get /apis is invoked with following parameter
>>> combination ?
>>>
>>> expand=true
>>> query=name:testAPI (any query that does not contain a label search)
>>>
>>> Should we return the APIList with full API details or return an error
>>> code to indicate this operation is not supported ?
>>>
>>
>> May be responding with *501 Not Implemented?* Shall we also indicate in
>> the response error description in the ErrorDTO that, expand attribute is
>> only supported when provided label search query? Let's mention the same in
>> the "expand" attribute description in the yaml file as well.
>>
>> Thanks!
>>
>>
>>>
>>> Appreciate your suggestions.
>>>
>>> Thanks,
>>> Sachini
>>>
>>> On Thu, May 17, 2018 at 10:53 PM, Ishara Cooray 
>>> wrote:
>>>
 Using /export might confuse with the api export API we have for API
 Manager 3.0. We should probably use the GET /apis Resource for this as
 well.
 +1

 Since we need to omit pagination (because in this case we need all
 results) we may need to do something like this

 GET /apis?limit=unlimited

 Omitting pagination may lead to out of memory issue if it returns a
 large JSON.
 What could be the maximum no of APIs that a lable can have?

 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 On Thu, May 17, 2018 at 11:55 AM, Nuwan Dias  wrote:

>
>
> On Thu, May 17, 2018 at 11:49 AM, Malintha Amarasinghe <
> malint...@wso2.com> wrote:
>
>>
>>
>> On Thu, May 17, 2018 at 10:57 AM Nuwan Dias  wrote:
>>
>>> Using /export might confuse with the api export API we have for API
>>> Manager 3.0. We should probably use the GET /apis Resource for this as
>>> well.
>>>
>>> Since we need to search by label, we'll probably need to filter as
>>> below
>>>
>>> GET /apis?query=label:foo
>>>
>>> Since we need to omit pagination (because in this case we need all
>>> results) we may need to do something like this
>>>
>>> GET /apis?limit=unlimited
>>>
>> The limit is currently defined as a number. How about limit=-1? Or we
>> have to change the limit data type to string.
>>
>
> +1
>
>>
>>
>>> The GET /apis responds with a partial payload for listing purposes.
>>> Since that doesn't work in this case we probably need to support a query
>>> param named 'expand'. Ex:
>>>
>>> GET /apis?expand=true
>>>
>>> We may need to honor the Accept header to decide on compression. Ex:
>>>
>>> Accept: application/gzip
>>>
>>> On Wed, May 16, 2018 at 6:38 PM, Ishara Cooray 
>>> wrote:
>>>
 Hi Sachini,

 Since the response could have more than 1 APIs you will have to
 consider about pagination as well.

 For that, you may use existing *APIList *resource in the
 publisher-api.yaml

 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 On Tue, May 15, 2018 at 10:08 AM, Sachini De Silva <
 sachi...@wso2.com> wrote:

> Hi Harsha,
>
> Yes, the response contains the swagger definition of APIs and all
> fields in APIDTO. As for the current implementation labeled apis are
> returned as a json list. (see response.json) To accommodate this I 
> have
> introduced a new DetailedAPIListDTO as below.
>
> DetailedAPIList:
> title: Detailed API List
> properties:
>   list:
> type: array
> items:
>   $ref: '#/definitions/API'
>
> At the moment I am working 

Re: [Architecture] [APIM][API-Manager gateway] REST API to Fetch API Details to APIM-Gateway

[Sachini De Silva]

Hi,

As per the discussion with team, we are going to send full APIDeatils
whenever get /apis is invoked with expand parameter set as true. In short
expand parameter would not be bound to just api labels feature but will
have the implied meaning in the context. (i.e whatever the resultant API
list will be returned with full details)

Thanks,
Sachini

On Tue, May 22, 2018 at 12:09 PM, Malintha Amarasinghe 
wrote:

>
>
> On Tue, May 22, 2018 at 11:25 AM Sachini De Silva 
> wrote:
>
>> Hi all,
>>
>> This is to clarify a doubt.
>>
>> What should be done when get /apis is invoked with following parameter
>> combination ?
>>
>> expand=true
>> query=name:testAPI (any query that does not contain a label search)
>>
>> Should we return the APIList with full API details or return an error
>> code to indicate this operation is not supported ?
>>
>
> May be responding with *501 Not Implemented?* Shall we also indicate in
> the response error description in the ErrorDTO that, expand attribute is
> only supported when provided label search query? Let's mention the same in
> the "expand" attribute description in the yaml file as well.
>
> Thanks!
>
>
>>
>> Appreciate your suggestions.
>>
>> Thanks,
>> Sachini
>>
>> On Thu, May 17, 2018 at 10:53 PM, Ishara Cooray  wrote:
>>
>>> Using /export might confuse with the api export API we have for API
>>> Manager 3.0. We should probably use the GET /apis Resource for this as
>>> well.
>>> +1
>>>
>>> Since we need to omit pagination (because in this case we need all
>>> results) we may need to do something like this
>>>
>>> GET /apis?limit=unlimited
>>>
>>> Omitting pagination may lead to out of memory issue if it returns a
>>> large JSON.
>>> What could be the maximum no of APIs that a lable can have?
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Thu, May 17, 2018 at 11:55 AM, Nuwan Dias  wrote:
>>>


 On Thu, May 17, 2018 at 11:49 AM, Malintha Amarasinghe <
 malint...@wso2.com> wrote:

>
>
> On Thu, May 17, 2018 at 10:57 AM Nuwan Dias  wrote:
>
>> Using /export might confuse with the api export API we have for API
>> Manager 3.0. We should probably use the GET /apis Resource for this as
>> well.
>>
>> Since we need to search by label, we'll probably need to filter as
>> below
>>
>> GET /apis?query=label:foo
>>
>> Since we need to omit pagination (because in this case we need all
>> results) we may need to do something like this
>>
>> GET /apis?limit=unlimited
>>
> The limit is currently defined as a number. How about limit=-1? Or we
> have to change the limit data type to string.
>

 +1

>
>
>> The GET /apis responds with a partial payload for listing purposes.
>> Since that doesn't work in this case we probably need to support a query
>> param named 'expand'. Ex:
>>
>> GET /apis?expand=true
>>
>> We may need to honor the Accept header to decide on compression. Ex:
>>
>> Accept: application/gzip
>>
>> On Wed, May 16, 2018 at 6:38 PM, Ishara Cooray 
>> wrote:
>>
>>> Hi Sachini,
>>>
>>> Since the response could have more than 1 APIs you will have to
>>> consider about pagination as well.
>>>
>>> For that, you may use existing *APIList *resource in the
>>> publisher-api.yaml
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Tue, May 15, 2018 at 10:08 AM, Sachini De Silva <
>>> sachi...@wso2.com> wrote:
>>>
 Hi Harsha,

 Yes, the response contains the swagger definition of APIs and all
 fields in APIDTO. As for the current implementation labeled apis are
 returned as a json list. (see response.json) To accommodate this I have
 introduced a new DetailedAPIListDTO as below.

 DetailedAPIList:
 title: Detailed API List
 properties:
   list:
 type: array
 items:
   $ref: '#/definitions/API'

 At the moment I am working on compressing the response.

 Thanks,
 Sachini


 On Mon, May 14, 2018 at 5:39 PM, Harsha Kumara 
 wrote:

> Hi Sachini,
>
> Is swagger definition embed with the response returning from this
> API?
>
> Thanks,
> Harsha
>
> On Wed, May 9, 2018 at 2:49 PM Sachini De Silva 
> wrote:
>
>> Hi,

Re: [Architecture] [APIM][API-Manager gateway] REST API to Fetch API Details to APIM-Gateway

[Malintha Amarasinghe]

On Tue, May 22, 2018 at 11:25 AM Sachini De Silva  wrote:

> Hi all,
>
> This is to clarify a doubt.
>
> What should be done when get /apis is invoked with following parameter
> combination ?
>
> expand=true
> query=name:testAPI (any query that does not contain a label search)
>
> Should we return the APIList with full API details or return an error code
> to indicate this operation is not supported ?
>

May be responding with *501 Not Implemented?* Shall we also indicate in the
response error description in the ErrorDTO that, expand attribute is only
supported when provided label search query? Let's mention the same in the
"expand" attribute description in the yaml file as well.

Thanks!


>
> Appreciate your suggestions.
>
> Thanks,
> Sachini
>
> On Thu, May 17, 2018 at 10:53 PM, Ishara Cooray  wrote:
>
>> Using /export might confuse with the api export API we have for API
>> Manager 3.0. We should probably use the GET /apis Resource for this as
>> well.
>> +1
>>
>> Since we need to omit pagination (because in this case we need all
>> results) we may need to do something like this
>>
>> GET /apis?limit=unlimited
>>
>> Omitting pagination may lead to out of memory issue if it returns a large
>> JSON.
>> What could be the maximum no of APIs that a lable can have?
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Thu, May 17, 2018 at 11:55 AM, Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Thu, May 17, 2018 at 11:49 AM, Malintha Amarasinghe <
>>> malint...@wso2.com> wrote:
>>>


 On Thu, May 17, 2018 at 10:57 AM Nuwan Dias  wrote:

> Using /export might confuse with the api export API we have for API
> Manager 3.0. We should probably use the GET /apis Resource for this as
> well.
>
> Since we need to search by label, we'll probably need to filter as
> below
>
> GET /apis?query=label:foo
>
> Since we need to omit pagination (because in this case we need all
> results) we may need to do something like this
>
> GET /apis?limit=unlimited
>
 The limit is currently defined as a number. How about limit=-1? Or we
 have to change the limit data type to string.

>>>
>>> +1
>>>


> The GET /apis responds with a partial payload for listing purposes.
> Since that doesn't work in this case we probably need to support a query
> param named 'expand'. Ex:
>
> GET /apis?expand=true
>
> We may need to honor the Accept header to decide on compression. Ex:
>
> Accept: application/gzip
>
> On Wed, May 16, 2018 at 6:38 PM, Ishara Cooray 
> wrote:
>
>> Hi Sachini,
>>
>> Since the response could have more than 1 APIs you will have to
>> consider about pagination as well.
>>
>> For that, you may use existing *APIList *resource in the
>> publisher-api.yaml
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Tue, May 15, 2018 at 10:08 AM, Sachini De Silva > > wrote:
>>
>>> Hi Harsha,
>>>
>>> Yes, the response contains the swagger definition of APIs and all
>>> fields in APIDTO. As for the current implementation labeled apis are
>>> returned as a json list. (see response.json) To accommodate this I have
>>> introduced a new DetailedAPIListDTO as below.
>>>
>>> DetailedAPIList:
>>> title: Detailed API List
>>> properties:
>>>   list:
>>> type: array
>>> items:
>>>   $ref: '#/definitions/API'
>>>
>>> At the moment I am working on compressing the response.
>>>
>>> Thanks,
>>> Sachini
>>>
>>>
>>> On Mon, May 14, 2018 at 5:39 PM, Harsha Kumara 
>>> wrote:
>>>
 Hi Sachini,

 Is swagger definition embed with the response returning from this
 API?

 Thanks,
 Harsha

 On Wed, May 9, 2018 at 2:49 PM Sachini De Silva 
 wrote:

> Hi,
>
> @Harsha Decided to return all information in APIDTO for each API
> as the response. (not only swagger definition, name, version, context 
> and
> provider)
>
> Thanks,
> Sachini
>
> On Wed, May 9, 2018 at 1:59 PM, Harsha Kumara 
> wrote:
>
>> @Sachini Can you also add a sample response as well?
>>
>> On Wed, May 9, 2018 at 8:02 AM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>> Hi,
>>>
>>>
>>> On Tue,