Maybe we can have two tables, that is one extra table to have the values
(multi valued attribute as shown below) related to the main category.

[image: Screen Shot 2019-11-20 at 11.42.41 AM.png]

Thanks & Regards,
Mushthaq

On Wed, Nov 20, 2019 at 10:40 AM Mushthaq Rumy <[email protected]> wrote:

> Hi,
>
> I too don't see much difference between the tags model and the current
> proposed model. As Sanjeewa mentioned the only difference seems to be that
> in this case admin will be adding the categories. IMO, if we are to have a
> value from this feature we will have to do something similar to the
> categorization feature done in WSO2 Governance Registry [1]. Here [1], we
> have used RXT to add the categories but it is not recommended to change
> RXTs as there will be migration issues. We will have to do something
> similar to that but with a different design approach.
>
> [1] -
> https://docs.wso2.com/display/Governance540/Refining+the+Search+Results
>
> Thanks & Regards,
> Mushthaq
>
> On Wed, Nov 13, 2019 at 4:10 PM Shani Ranasinghe <[email protected]> wrote:
>
>> Hi,
>> Is my understanding on our different grouping methods, as stated below,
>> correct?
>> 1) API Labels - used when want to group APIs and deploy them on a MGW
>> 2) API tags - to group APIs based on specific functionality if offers
>> (down to resource level), and to make search easier
>> 3) API Category Labels - to group APIs based on the main business
>> offering, and to make it more searchable on the dev portal
>>
>> I have a few suggestions to avoid confusions about the different grouping
>> terms we have in the product.
>>
>> 1) With API Labels, if we call it a way of grouping APIs, I think it
>> would confuse our customers. Because ideally, if someone searches for
>> grouping APIs, API categories should appear on the search result. To avoid
>> confusion, shall we describe it as "API deployment Package" /  "API
>> Package"  and have the content heading as "Deploying API Packages" under
>> MGW docs? But then again, we also have API Products, which is also a
>> packaging concept. Any other suggestions?
>>
>> 2) We have "API Monetization Category Labels" . Are we still considering
>> it as a label or, should we call it, "API monetization model" I feel it's
>> more than a label, and it defines actually a monetization model. WDYT?
>>
>> On Wed, Nov 13, 2019 at 12:35 PM Malintha Amarasinghe <[email protected]>
>> wrote:
>>
>>> Earlier we supported a thumbnail per group. Do we plan to support that
>>> too?
>>>
>>> Thanks!
>>>
>>> On Wed, Nov 13, 2019 at 12:32 PM Bhathiya Jayasekara <[email protected]>
>>> wrote:
>>>
>>>> We can replace tag-groups with categories, and keep tags as it is which
>>>> is helpful in searches.
>>>>
>>>> Thanks,
>>>> Bhathiya
>>>>
>>>> On Wed, Nov 13, 2019 at 12:30 PM Sanjeewa Malalgoda <[email protected]>
>>>> wrote:
>>>>
>>>>> If we have API categories then tag wise store view will not need
>>>>> anymore. As i remember tagwise store view working till last release.
>>>>> Only difference between categories and tags is categories created by
>>>>> admin while tags created by API creator. Do we have any other differences
>>>>> or specific use cases address by this?
>>>>>
>>>>> Thanks,
>>>>> sanjeewa.
>>>>>
>>>>> On Wed, Nov 13, 2019 at 12:22 PM Sachini De Silva <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> @Harsha Kumara <[email protected]>  will switch to tenant id.
>>>>>>
>>>>>> @Nuwan Dias <[email protected]>  +1 will add a single scope
>>>>>> ‘apim:api_category’ to do all api categories related operations.
>>>>>>
>>>>>> In publisher, categories/ GET resource can be associated with
>>>>>> apim:api_view scope. In store we can avoid attaching a scope to 
>>>>>> categories/
>>>>>> GET resource and allow to access the resource without a token.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 13, 2019 at 11:50 AM Nuwan Dias <[email protected]> wrote:
>>>>>>
>>>>>>> For the admin API, I don't think we need separate scopes for the
>>>>>>> read and write of categories, isn't it?
>>>>>>>
>>>>>>> The publisher and store APIs would also need an API each to fetch
>>>>>>> the categories. These can be bound to already available scopes I assume.
>>>>>>>
>>>>>>> On Wed, Nov 13, 2019 at 11:26 AM Sachini De Silva <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> On Wed, Nov 13, 2019 at 11:13 AM Bhathiya Jayasekara <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Shall we use "API Categories" everywhere instead of just
>>>>>>>>> "Categories"? Because in the future there can be other category types 
>>>>>>>>> too.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Bhathiya
>>>>>>>>>
>>>>>>>>> On Wed, Nov 13, 2019 at 10:59 AM Sachini De Silva <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I am working on a new feature ‘API Categories’. It is very
>>>>>>>>>> similar to tag wise grouping in store from a store UI POV but has the
>>>>>>>>>> following differences w.r.t tags.
>>>>>>>>>> 1. Categories define a broader collection of APIs. Tags can be
>>>>>>>>>> used by the publisher to emphasize specific details of an API.
>>>>>>>>>> 2. Categories have to be pre-defined by an Admin before they can
>>>>>>>>>> be associated with any APIs.
>>>>>>>>>> 3. Categories can have any valid string as their category name.
>>>>>>>>>> Whereas tag wise groups must have the suffix -group to be identified 
>>>>>>>>>> as a
>>>>>>>>>> tag group.
>>>>>>>>>>
>>>>>>>>>> In order to support this in APIM, I thought of using the
>>>>>>>>>> following approach.
>>>>>>>>>> 1. Define a REST API to do operations on category resources.
>>>>>>>>>> Sample GET and POST resources would be as below.
>>>>>>>>>>
>>>>>>>>>> *"/categories"*: {  *"get"*: {    *"x-scope"*: 
>>>>>>>>>> *"apim:category_read"*,    *"x-wso2-request"*: *"GET 
>>>>>>>>>> https://localhost:9443/api/am/admin/v0.15/categories 
>>>>>>>>>> <https://localhost:9443/api/am/admin/v0.15/categories>**\n**Authorization:
>>>>>>>>>>  Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8**\n**"*,    
>>>>>>>>>> *"x-wso2-curl"*: *"curl -k -H **\"**Authorization: Bearer 
>>>>>>>>>> ae4eae22-3f65-387b-a171-d37eaa366fa8**\" 
>>>>>>>>>> \"**https://localhost:9443/api/am/admin/v0.15/categories 
>>>>>>>>>> <https://localhost:9443/api/am/admin/v0.15/categories>**\"**"*,    
>>>>>>>>>> *"x-wso2-response"*: *"HTTP/1.1 200 OK**\r\n**Content-Type: 
>>>>>>>>>> application/json**\r\n\r\n**{**\r\n   \"**count**\"**:1,**\r\n   
>>>>>>>>>> \"**list**\"**:[**\r\n*      *{**\r\n         
>>>>>>>>>> \"**id**\"**:**\"**463e2c9f-5e99-43c3-a66e-de7e0f367373**\"**,**\r\n 
>>>>>>>>>>         \"**name**\"**:**\"**Finance**\"**,**\r\n         
>>>>>>>>>> \"**description**\"**:**\"**Finance related APIS**\"\r\n*      
>>>>>>>>>> *}**\r\n*   *]**\r\n**}"*,    *"summary"*: *"Get all API 
>>>>>>>>>> categories"*,    *"description"*: *"Get all API categories**\n**"*,  
>>>>>>>>>>   *"tags"*: [      *"Category Collection"*    ],    *"responses"*: { 
>>>>>>>>>>      *"200"*: {        *"description"*: *"OK.**\n**Categories 
>>>>>>>>>> returned**\n**"*,        *"schema"*: {          *"$ref"*: 
>>>>>>>>>> *"#/definitions/**Category**List"*        }      }    }  },  
>>>>>>>>>> *"post"*: {    *"x-scope"*: *"apim:category_manage"*,    
>>>>>>>>>> *"x-wso2-curl"*: *"curl -k -X POST -H **\"**Authorization: Bearer 
>>>>>>>>>> 0d63e133-7ad6-3aeb-9ca9-9299e0708122**\"* *-H **\"**Content-Type: 
>>>>>>>>>> application/json**\"* *https://apis.wso2.com/api/am/admin/v0.15/ 
>>>>>>>>>> <https://apis.wso2.com/api/am/admin/v0.15/>**categorie**s -d 
>>>>>>>>>> @data.json"*,    *"x-wso2-request"*: *"POST 
>>>>>>>>>> https://localhost:9443/api/am/admin/v0.15/categories 
>>>>>>>>>> <https://localhost:9443/api/am/admin/v0.15/categories>**\r\n**Authorization:
>>>>>>>>>>  Bearer 0d63e133-7ad6-3aeb-9ca9-9299e0708122**\r\n**Content-Type: 
>>>>>>>>>> application/json**\r\n\r\n* *-d  {**\r\n         
>>>>>>>>>> \"**name**\"**:**\"**Finance**\"**,**\r\n         
>>>>>>>>>> \"**description**\"**:**\"**Finance related APIS**\"\r\n* *}"*,    
>>>>>>>>>> *"x-wso2-response"*: *"HTTP/1.1 201 Created**\r\n**Content-Type: 
>>>>>>>>>> application/json**\r\n\r\n**{**\r\n   \"**count**\"**:1,**\r\n   
>>>>>>>>>> \"**list**\"**:[**\r\n*      *{**\r\n         
>>>>>>>>>> \"**id**\"**:**\"**463e2c9f-5e99-43c3-a66e-de7e0f367373**\"**,**\r\n 
>>>>>>>>>>         \"**name**\"**:**\"**Finance**\"**,**\r\n         
>>>>>>>>>> \"**description**\"**:**\"**Finance related APIS**\"\r\n*      
>>>>>>>>>> *}**\r\n*   *]**\r\n**}"*,    *"summary"*: *"Add a Category"*,    
>>>>>>>>>> *"description"*: *"Add a new API Category**\n**"*,    
>>>>>>>>>> *"parameters"*: [      {        *"in"*: *"body"*,        *"name"*: 
>>>>>>>>>> *"body"*,        *"description"*: *"Category object that should to 
>>>>>>>>>> be added**\n**"*,        *"required"*: *true*,        *"schema"*: {  
>>>>>>>>>>         *"$ref"*: *"#/definitions/Category"*        }      }    ],   
>>>>>>>>>>  *"tags"*: [      *"Category"*    ],    *"responses"*: {      
>>>>>>>>>> *"201"*: {        *"description"*: *"Created.**\n**Successful 
>>>>>>>>>> response with the newly created object as entity in the 
>>>>>>>>>> body.**\n**"*,        *"schema"*: {          *"$ref"*: 
>>>>>>>>>> *"#/definitions/Category"*        }      },      *"400"*: {        
>>>>>>>>>> *"description"*: *"Bad Request.**\n**Invalid request or validation 
>>>>>>>>>> error**\n**"*,        *"schema"*: {          *"$ref"*: 
>>>>>>>>>> *"#/definitions/Error"*        }      }    }  }}
>>>>>>>>>>
>>>>>>>>>> And category and categoryList would be defined as below.
>>>>>>>>>>
>>>>>>>>>> *"Category"*: {    *"title"*: *"Category"*,    *"required"*: [      
>>>>>>>>>> *"name"*    ],    *"properties"*: {      *"id"*: {        *"type"*: 
>>>>>>>>>> *"string"*,        *"example"*: 
>>>>>>>>>> *"01234567-0123-0123-0123-012345678901"*      },      *"name"*: {    
>>>>>>>>>>     *"type"*: *"string"*,        *"example"*: *"Finance"*      },    
>>>>>>>>>>   *"description"*: {        *"type"*: *"string"*,        
>>>>>>>>>> *"example"*: *"Finance related APIs"*      }    }  },  
>>>>>>>>>> *"CategoryList"*: {    *"title"*: *"Category List"*,    
>>>>>>>>>> *"properties"*: {      *"count"*: {        *"type"*: *"integer"*,    
>>>>>>>>>>     *"description"*: *"Number of categories returned.**\n**"*,       
>>>>>>>>>>  *"example"*: 1      },      *"list"*: {        *"type"*: *"array"*, 
>>>>>>>>>>        *"items"*: {          *"$ref"*: *"#/definitions/Category"*    
>>>>>>>>>>     }      }    }  }}
>>>>>>>>>>
>>>>>>>>>> 2. Define a new AM_CATEGORIES table to hold category related
>>>>>>>>>> details.
>>>>>>>>>>
>>>>>>>>>> *CREATE TABLE *IF *NOT EXISTS *AM_CATEGORIES (  CATEGORY_ID 
>>>>>>>>>> *VARCHAR*(50),  NAME *VARCHAR*(255),  DESCRIPTION *VARCHAR*(1024),  
>>>>>>>>>> TENANT_DOMAIN *VARCHAR*(255),  *UNIQUE *(NAME,TENANT_DOMAIN),  
>>>>>>>>>> *PRIMARY KEY *(CATEGORY_ID));
>>>>>>>>>>
>>>>>>>>>> 3. Publisher UI overview tab(or a suitable place as it fits) will
>>>>>>>>>> have a new UI element to select categories for the API. And selecting
>>>>>>>>>> categories for an API would be optional.
>>>>>>>>>>
>>>>>>>>>> 4. API to category mapping will be stored in registry API
>>>>>>>>>> artifact and for that following table field would have to be added to
>>>>>>>>>> api.rxt. (I assume we are going to support associating a single API 
>>>>>>>>>> with
>>>>>>>>>> multiple categories)
>>>>>>>>>> <table name="Categories" columns="1"  maxoccurs="unbounded">
>>>>>>>>>>             <subheading>
>>>>>>>>>>                 <heading>Category Name</heading>
>>>>>>>>>>             </subheading>
>>>>>>>>>>             <field type="text">
>>>>>>>>>>                 <name label="Category Name">categoryName</name>
>>>>>>>>>>             </field>
>>>>>>>>>>  </table>
>>>>>>>>>>
>>>>>>>>>> 5. And from store viewing POV, I assume API categories are a
>>>>>>>>>> substitution for existing tag-wise grouping feature and that both 
>>>>>>>>>> tag-wise
>>>>>>>>>> groups and categories won’t co-exist in the store. Please do correct 
>>>>>>>>>> if my
>>>>>>>>>> understanding is wrong.
>>>>>>>>>> Once a developer visits the store, he will be presented with the
>>>>>>>>>> list of API categories and upon selecting a category out of those,
>>>>>>>>>> associated APIs will be listed.
>>>>>>>>>> APIs that are not associated with any category will be listed
>>>>>>>>>> under other APIs or a similar heading.
>>>>>>>>>>
>>>>>>>>>> Please feel free to add your suggestions.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Sachini
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> *Sachini De Silva*
>>>>>>>>>> Senior Software Engineer - WSO2
>>>>>>>>>>
>>>>>>>>>> Email : [email protected]
>>>>>>>>>> Mobile : +94714765495
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc.
>>>>>>>>> (m) +94 71 547 8185  | (e) bhathiya-@t-wso2-d0t-com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Sachini De Silva*
>>>>>>>> Senior Software Engineer - WSO2
>>>>>>>>
>>>>>>>> Email : [email protected]
>>>>>>>> Mobile : +94714765495
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Nuwan Dias* | Director | WSO2 Inc.
>>>>>>> (m) +94 777 775 729 | (e) [email protected]
>>>>>>> [image: Signature.jpg]
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Sachini De Silva*
>>>>>> Senior Software Engineer - WSO2
>>>>>>
>>>>>> Email : [email protected]
>>>>>> Mobile : +94714765495
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> *Sanjeewa Malalgoda*
>>>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>>>> (m) +94 712933253 | (e) [email protected] | (b) Blogger
>>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>>>> <https://medium.com/@sanjeewa190>
>>>>>
>>>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>>>> Integration Agility for Digitally Driven Business
>>>>>
>>>>
>>>>
>>>> --
>>>> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc.
>>>> (m) +94 71 547 8185  | (e) bhathiya-@t-wso2-d0t-com
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>> --
>> Thanks and Regards
>> *,**Shani Ranasinghe* | Associate Lead - Technical Writer | WSO2 Inc
>> <https://wso2.com/>
>> (M) +94 772 273 555 | (E) [email protected]
>>
>> <http://wso2.com/signature>
>>
>> <https://mail.google.com/http://wso2.com/signature>
>> :
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Mushthaq Rumy
> *Senior Software Engineer*
> Mobile : +94 (0) 779 492140
> Email : [email protected]
> WSO2, Inc.; http://wso2.com/
> lean . enterprise . middleware.
>
> <http://wso2.com/signature>
>


-- 
Mushthaq Rumy
*Senior Software Engineer*
Mobile : +94 (0) 779 492140
Email : [email protected]
WSO2, Inc.; http://wso2.com/
lean . enterprise . middleware.

<http://wso2.com/signature>
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to