Re: [Architecture] Deployment Automation - Clustering with large number of nodes
Hi All, Moving on with Deployment Automation, we are evaluating a tool for deploying cross platform setup in order to integrate with 3rd party products with deployment framework. Main concerns are 1. Testing actoss multiple environments (OS, JVM, DBs etc). 2. Limitness of resources to maintain seperate environments of different servers, JVMs, OS and diffeent versions of differnt serves. 3. Eazy to manage configurations. 4. Ability to work with open stack, EC2 and local networks. Currently we are planning to eveluate Vagrant [1] based solution to achieve this As first phase we are planning to implement a solution based on Virtual box and OpenStack. [1]. https://www.vagrantup.com/ Thank You, Dharshana. On Mon, Jan 5, 2015 at 3:45 PM, Suhan Dharmasuriya suh...@wso2.com wrote: Thanks Manula. Will look for the possibility and move the central puppet config.pp file contents out of the module. Thanks, Suhan On Mon, Jan 5, 2015 at 3:09 PM, Manula Waidyanatha man...@wso2.com wrote: Hi Suhan, You have to use regex if you want to have different configurations for each server (hostname). If you can move all the node specific data out of the module (to node.pp or site.pp) On Mon, Jan 5, 2015 at 10:45 AM, Suhan Dharmasuriya suh...@wso2.com wrote: Hi, Test Automation team is currently in to RD of deployment automation. Currently we are focusing on deployment of WSO2 Application Server clusters of worker manager pattern. As of now, we have configured deployment automation in a way that the cluster node names in a deployment configuration file [1] and the product configuration information (appserver's axis2.xml, carbon.xml, etc...) in a config.pp [2] file which will be placed as /etc/puppet/modules/appserver/params.pp after running the main python script. Therefore when new instances are spawned in OpenStack according to the node names in config file [1] puppet agents pre-installed in them will retrieve their respective xml configurations from /etc/puppet/modules/appserver/params.pp file and perform puppet catalog runs. Refer Github repo [3] python_scripts for more clarifications. Currently node names are matched directly against the product configuration puppet file $servers names [2]. Our next step is to give the number of worker/manager subdomain node combination and spawn the cluster in to existence on OpenStack environment. We are planning of fronting an elb for each worker/manager subdomain. Then, our deployment.cfg file will be modified as follows by indicating the number of sub domain nodes. [nodes] appserver-mgr = 10 appserver-wkr = 20 config.pp file will be as follows. $servers = { appserver-mgr = { axis2 = {subDomain = 'mgt', members = ['elb1-ip', 'elb2-ip']}, carbon = {subDomain = 'mgt',}, serverOptions = '-Dsetup', server_home = $carbon_home, }, appserver- wkr = { axis2 = {subDomain = 'worker', members = ['elb1-ip', ' elb2-ip']}, carbon = {subDomain = 'worker',}, serverOptions = ' -DworkerNode=true', server_home = $carbon_home, }, } Instances will be spawned in OpenStack as follows. appserver-mgr-1 appserver-mgr-2 ... appserver-mgr-10 appserver-wkr-1 appserver-wkr-2 ... appserver-wkr-20 How can I match the new server names against the new product configuration file? Can I use regular expressions? Is it a recommended approach? Is there any better alternative for pushing product configurations in terms of standards, practices and performance for clusters with large number of nodes? [1] https://github.com/suhand/Deployment-Automation/blob/master/deployment-automation-total-puppet/python_scripts/deployment.cfg [2] https://github.com/suhand/Deployment-Automation/blob/master/deployment-automation-total-puppet/python_scripts/config.pp [3] https://github.com/suhand/Deployment-Automation/tree/master/deployment-automation-total-puppet Thanks, Suhan -- Suhan Dharmasuriya Software Engineer - Test Automation *WSO2, Inc. * lean . enterprise . middleware Tel: +94 112 145345 Mob: +94 779 869138 Blog: http://suhan-opensource.blogspot.com/ -- Regards, Manula Waidyanatha Systems Engineer, WSO2, Inc. Phone: +94 774 195853 Blog: blog.manula.org -- Suhan Dharmasuriya Software Engineer - Test Automation *WSO2, Inc. * lean . enterprise . middleware Tel: +94 112 145345 Mob: +94 779 869138 Blog: http://suhan-opensource.blogspot.com/ -- Dharshana Warusavitharana Senior Software Engineer , Test Automation WSO2 Inc. http://wso2.com email : dharsha...@wso2.com dharsha...@wso2.com Tel : +94 11 214 5345 Fax :+94 11 2145300 cell : +94770342233 blog : http://dharshanaw.blogspot.com lean . enterprise . middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] BAM 3.0 REST APIs for AnalyticsDataService / Indexing / Search
Hi Harshan, Thanks for the feedback. The list of IDs of the records to be retrieved can be too long. So setting a list of ids as a query param is not convenient. Even for the Search, we have to pass a query, which can be too long. Thats why the post method is used for Search. Thanks, On Tue, Jan 20, 2015 at 12:52 PM, Sinthuja Ragendran sinth...@wso2.com wrote: Hi Gimantha, I think following the conventions will be more intuitive to the users, and we should have a proper reason to not follow. And the post request is generally needs to be sent to create the object and the back end is going to decide where to create the tables resource, therefore it should be POST to '/analytics/tables' and message body should be having the table name. If you want to use /analytics/{tableName}, then you should use PUT rather POST [1]. But IMO POST is the most suitable operation for this context. And through out the below given URL patterns, in order to fetch the records from a table, you have used '/analytics/records/{tableName}' url pattern where 'records' is in the middle and it is not the correct data hierarchy and again I feel it's not the convention. Basically tables contains records and not records contains tables. Therefore if we use POST to '/analytics/tables' for create table, then you can use simply user 'analytics/{tableName}' to GET/POST for the tables, IMHO the records is just an additional segment which is not needed to be here. [1] http://restcookbook.com/HTTP%20Methods/put-vs-post Thanks, Sinthuja. On Tue, Jan 20, 2015 at 1:29 AM, Gimantha Bandara giman...@wso2.com wrote: Hi Sinduja, Thank you for the feedback. On Mon, Jan 19, 2015 at 12:04 PM, Sinthuja Ragendran sinth...@wso2.com wrote: Hi gimantha, Please see the comments inline. On Sun, Jan 18, 2015 at 11:24 PM, Gimantha Bandara giman...@wso2.com wrote: Hi, Currently, I am working on $subject. Basically the methods in AnalyticsDataService will be exposed through REST APIs. Please refer to Architecture mail thread *[Architecture] BAM 3.0 Data Layer Implementation / RDBMS / Distributed Indexing / Search* for more Details. Following are the supported REST APIs. 1. Create a table *POST /analytics/{tableName}* ; tableName - The name of the table to be created. IMHO the above should be POST to '/analytics/*tables*' and the request content should have the table name as given below. { tableName : Test } Since the POST takes only the table name, it is straightforward to use it as a path parameter. 2. Delete a table *DELETE /analytics/{tableName} * ; tableName - The name of the table to be deleted. 3. Check if a table exists *GET /analytics/{tableName} * ; tableName - The name of the table being checked. 4. List All the tables *GET /analytics/tables* ;Response will be an JSON array of table names. e.g. [ table1 , table2 , table3 ] 5. Get the records from a table. *GET /analytics/records/{tableName}/{from}/{to}/{start}/{count} * ; tableName - The name of the table from which the records are retrieved. ; from - The starting time to get records from. ; to - The ending time to get records to. ; start - The paginated index from value ; count - The paginated records count to be read ; response - takes the format of the request content of No.7 Do we need to have 'records' in the URL? I think it's better to have */analytics/{tableName}/{from}/{to}/{start}/{count} * records is there to avoid conflicts with other contexts. As an example, If we remove records, the URL will take the format /analytics/{tableName}, which is already a defined REST API. 6. Get the records from a table (By IDs) *POST /analytics/records/{tableName}* ; tableName - The name of the table from which the records are retrieved. ; Content - A List of IDs of the records to be retrieved in the following format. [ id1 , id2 , id3 ] ; response - takes the format of the request content of No.7 Similarly can we have this as * /analytics/{tableName}?* 7. Create records ( can be created in different tables or in the same ) *POST /analytics/records* ; Content - A list of records in json format like in below. [ { id: id1, tenantId: -1234, tableName: tableName1, timestamp: -mm-dd hh:mm:ss, values: { columnName1: value1, columnName2: value2 } }, { id: id2, tenantId: -1234, tableName: tableName2, timestamp: -mm-dd hh:mm:ss, values: { columnName1: value1, columnName2: value2 } }, ] 8. Delete records *DELETE /analytics/records/{tableName}/{timeFrom}/{timeTo}* ; tableName - Name of the table from which the records are deleted. ; timeFrom - The starting time to delete records from. ; timeTo - The end time to delete records to. Again do we need to have 'records' in the middle? IMHO
Re: [Architecture] BAM 3.0 REST APIs for AnalyticsDataService / Indexing / Search
Hi Gimantha, Could you please explain the use-case for the API #6? IMO there should not be any operation to fetch a list of records by ids. Instead there could be an API which sends a list of records as the response for a query. For the API #14 you can still use GET method with query strings. I think you have included start count parameters to control the pagination. For that you can use the HTTP range-header [1] or link headers as mentioned in [2]. [1]. http://otac0n.com/blog/2012/11/21/range-header-i-choose-you.html [2]. https://developer.github.com/v3/#pagination Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Jan 20, 2015 at 6:34 PM, Gimantha Bandara giman...@wso2.com wrote: Hi Harshan, Thanks for the feedback. The list of IDs of the records to be retrieved can be too long. So setting a list of ids as a query param is not convenient. Even for the Search, we have to pass a query, which can be too long. Thats why the post method is used for Search. Thanks, On Tue, Jan 20, 2015 at 12:52 PM, Sinthuja Ragendran sinth...@wso2.com wrote: Hi Gimantha, I think following the conventions will be more intuitive to the users, and we should have a proper reason to not follow. And the post request is generally needs to be sent to create the object and the back end is going to decide where to create the tables resource, therefore it should be POST to '/analytics/tables' and message body should be having the table name. If you want to use /analytics/{tableName}, then you should use PUT rather POST [1]. But IMO POST is the most suitable operation for this context. And through out the below given URL patterns, in order to fetch the records from a table, you have used '/analytics/records/{tableName}' url pattern where 'records' is in the middle and it is not the correct data hierarchy and again I feel it's not the convention. Basically tables contains records and not records contains tables. Therefore if we use POST to '/analytics/tables' for create table, then you can use simply user 'analytics/{tableName}' to GET/POST for the tables, IMHO the records is just an additional segment which is not needed to be here. [1] http://restcookbook.com/HTTP%20Methods/put-vs-post Thanks, Sinthuja. On Tue, Jan 20, 2015 at 1:29 AM, Gimantha Bandara giman...@wso2.com wrote: Hi Sinduja, Thank you for the feedback. On Mon, Jan 19, 2015 at 12:04 PM, Sinthuja Ragendran sinth...@wso2.com wrote: Hi gimantha, Please see the comments inline. On Sun, Jan 18, 2015 at 11:24 PM, Gimantha Bandara giman...@wso2.com wrote: Hi, Currently, I am working on $subject. Basically the methods in AnalyticsDataService will be exposed through REST APIs. Please refer to Architecture mail thread *[Architecture] BAM 3.0 Data Layer Implementation / RDBMS / Distributed Indexing / Search* for more Details. Following are the supported REST APIs. 1. Create a table *POST /analytics/{tableName}* ; tableName - The name of the table to be created. IMHO the above should be POST to '/analytics/*tables*' and the request content should have the table name as given below. { tableName : Test } Since the POST takes only the table name, it is straightforward to use it as a path parameter. 2. Delete a table *DELETE /analytics/{tableName} * ; tableName - The name of the table to be deleted. 3. Check if a table exists *GET /analytics/{tableName} * ; tableName - The name of the table being checked. 4. List All the tables *GET /analytics/tables* ;Response will be an JSON array of table names. e.g. [ table1 , table2 , table3 ] 5. Get the records from a table. *GET /analytics/records/{tableName}/{from}/{to}/{start}/{count} * ; tableName - The name of the table from which the records are retrieved. ; from - The starting time to get records from. ; to - The ending time to get records to. ; start - The paginated index from value ; count - The paginated records count to be read ; response - takes the format of the request content of No.7 Do we need to have 'records' in the URL? I think it's better to have */analytics/{tableName}/{from}/{to}/{start}/{count} * records is there to avoid conflicts with other contexts. As an example, If we remove records, the URL will take the format /analytics/{tableName}, which is already a defined REST API. 6. Get the records from a table (By IDs) *POST /analytics/records/{tableName}* ; tableName - The name of the table from which the records are retrieved. ; Content - A List of IDs of the records to be retrieved in the following format. [ id1 , id2 , id3 ] ; response - takes the format of the request content of No.7 Similarly can we have this as * /analytics/{tableName}?* 7. Create records ( can be created in different tables or in the same ) *POST
Re: [Architecture] Maintaining carbon-store GitHub repo
Hi all, I have completed basic repo separation discussed above along with commit history of the code base.(https://github.com/ayshsandu/carbon-store). I still need to include some necessary resource directories to this repo for it to be fully functional. There are 3 folders listed under product-es/disribution/src [1] - *product-es/disribution/src/dbscripts/storage* [2] - contains ES storage related dbscripts and exported from org.wso2.es.feature and org.wso2.store.feature. - In our repo separation we should move this to *carbon-store* repo. - I suggest this can be located in below directory structure in *carbon-store* repo, and update export paths in org.wso2.es.feature and org.wso2.store.feature. - *carbon-store/features/resources/dbscripts* - Otherwise where should this be located? - *product-es/distribution/src/repository *[3] - This folder is also exported from org.wso2.es.feature and org.wso2.store.feature. - There are several folders in this location and as I see most of them are ES prodouct specific. - I suggest that we keep product specific stuff in *product-es/disribution/src/repository* as it is and move other necessary files to *carbon-store/features/resources/repository *location and update export paths in org.wso2.es.feature and org.wso2.store.feature. - But I am having hard-time on exactly identifying files in *product-es/disribution/src/repository *location what are ES-product related and what should be exported from features. Please, advice on this separation. - *product-es/distribution/src/assembly* - This contains ES product specific files and will be kept in product-es as it is. Please suggest your concerns on above points. [1] https://github.com/wso2/product-es/tree/master/modules/distribution/src [2] https://github.com/wso2/product-es/tree/master/modules/distribution/src/dbscripts/storage [3] https://github.com/wso2/product-es/tree/master/modules/distribution/src/repository Thanks! - Ayesha On Mon, Jan 19, 2015 at 8:10 PM, Sagara Gunathunga sag...@wso2.com wrote: +1 Thanks ! On Mon, Jan 19, 2015 at 7:33 PM, Ayesha Dissanayaka aye...@wso2.com wrote: Hi, Please refer the repo structure mentioned above as below. Sorry about missing it fist-place. Thanks! -Ayesha On Mon, Jan 19, 2015 at 7:24 PM, Ayesha Dissanayaka aye...@wso2.com wrote: Hi all, I have started creating carbon-store GitHub repo as suggested in the mail thread Creating carbon-store GitHub repo. Along with *components* and *features* we will be moving *apps* and *jaggery-modules *into this repo. Finally the main repo structure would be like below. - *apps**[1] *will contain jaggeryapps we ship with ES pack and reused by other products. - *jaggery-modules* [2] are reusable and required by *apps* After completing this repo separation, other products which are using ES stuffs will be able to integrate all the ES related components via this *carbon-store *repo and will not be depend on *product-es*. What are the other inputs on this? How have APIM has exposed jaggery related components in this case? [1] https://github.com/wso2/product-es/tree/master/modules/apps [2] https://github.com/wso2/product-es/tree/master/modules/jaggery-modules/ Thanks! - Ayesha -- *Ayesha Dissanayaka* Software Engineer, WSO2, Inc : http://wso2.com http://www.google.com/url?q=http%3A%2F%2Fwso2.comsa=Dsntz=1usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg 20, Palmgrove Avenue, Colombo 3 E-Mail: aye...@wso2.com ayshsa...@gmail.com -- *Ayesha Dissanayaka* Software Engineer, WSO2, Inc : http://wso2.com http://www.google.com/url?q=http%3A%2F%2Fwso2.comsa=Dsntz=1usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg 20, Palmgrove Avenue, Colombo 3 E-Mail: aye...@wso2.com ayshsa...@gmail.com -- Sagara Gunathunga Senior Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services;http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com -- *Ayesha Dissanayaka* Software Engineer, WSO2, Inc : http://wso2.com http://www.google.com/url?q=http%3A%2F%2Fwso2.comsa=Dsntz=1usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg 20, Palmgrove Avenue, Colombo 3 E-Mail: aye...@wso2.com ayshsa...@gmail.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] BAM 3.0 REST APIs for AnalyticsDataService / Indexing / Search
Hi, Goood point!. Initially the search was implemented such a way that it returns a list of ids of records that match the query. Now the search method is changed, so it returns the records. So +1 for removing the API #6. @Sinduja, @Harshan Thanks for the reference links and for the feedback. On Tue, Jan 20, 2015 at 6:52 PM, Harshan Liyanage hars...@wso2.com wrote: Hi Gimantha, Could you please explain the use-case for the API #6? IMO there should not be any operation to fetch a list of records by ids. Instead there could be an API which sends a list of records as the response for a query. For the API #14 you can still use GET method with query strings. I think you have included start count parameters to control the pagination. For that you can use the HTTP range-header [1] or link headers as mentioned in [2]. [1]. http://otac0n.com/blog/2012/11/21/range-header-i-choose-you.html [2]. https://developer.github.com/v3/#pagination Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Jan 20, 2015 at 6:34 PM, Gimantha Bandara giman...@wso2.com wrote: Hi Harshan, Thanks for the feedback. The list of IDs of the records to be retrieved can be too long. So setting a list of ids as a query param is not convenient. Even for the Search, we have to pass a query, which can be too long. Thats why the post method is used for Search. Thanks, On Tue, Jan 20, 2015 at 12:52 PM, Sinthuja Ragendran sinth...@wso2.com wrote: Hi Gimantha, I think following the conventions will be more intuitive to the users, and we should have a proper reason to not follow. And the post request is generally needs to be sent to create the object and the back end is going to decide where to create the tables resource, therefore it should be POST to '/analytics/tables' and message body should be having the table name. If you want to use /analytics/{tableName}, then you should use PUT rather POST [1]. But IMO POST is the most suitable operation for this context. And through out the below given URL patterns, in order to fetch the records from a table, you have used '/analytics/records/{tableName}' url pattern where 'records' is in the middle and it is not the correct data hierarchy and again I feel it's not the convention. Basically tables contains records and not records contains tables. Therefore if we use POST to '/analytics/tables' for create table, then you can use simply user 'analytics/{tableName}' to GET/POST for the tables, IMHO the records is just an additional segment which is not needed to be here. [1] http://restcookbook.com/HTTP%20Methods/put-vs-post Thanks, Sinthuja. On Tue, Jan 20, 2015 at 1:29 AM, Gimantha Bandara giman...@wso2.com wrote: Hi Sinduja, Thank you for the feedback. On Mon, Jan 19, 2015 at 12:04 PM, Sinthuja Ragendran sinth...@wso2.com wrote: Hi gimantha, Please see the comments inline. On Sun, Jan 18, 2015 at 11:24 PM, Gimantha Bandara giman...@wso2.com wrote: Hi, Currently, I am working on $subject. Basically the methods in AnalyticsDataService will be exposed through REST APIs. Please refer to Architecture mail thread *[Architecture] BAM 3.0 Data Layer Implementation / RDBMS / Distributed Indexing / Search* for more Details. Following are the supported REST APIs. 1. Create a table *POST /analytics/{tableName}* ; tableName - The name of the table to be created. IMHO the above should be POST to '/analytics/*tables*' and the request content should have the table name as given below. { tableName : Test } Since the POST takes only the table name, it is straightforward to use it as a path parameter. 2. Delete a table *DELETE /analytics/{tableName} * ; tableName - The name of the table to be deleted. 3. Check if a table exists *GET /analytics/{tableName} * ; tableName - The name of the table being checked. 4. List All the tables *GET /analytics/tables* ;Response will be an JSON array of table names. e.g. [ table1 , table2 , table3 ] 5. Get the records from a table. *GET /analytics/records/{tableName}/{from}/{to}/{start}/{count} * ; tableName - The name of the table from which the records are retrieved. ; from - The starting time to get records from. ; to - The ending time to get records to. ; start - The paginated index from value ; count - The paginated records count to be read ; response - takes the format of the request content of No.7 Do we need to have 'records' in the URL? I think it's better to have */analytics/{tableName}/{from}/{to}/{start}/{count} * records is there to avoid conflicts with other contexts. As an example, If we remove records, the URL will take the format /analytics/{tableName}, which is already a defined REST API. 6. Get the records from a table (By IDs) *POST /analytics/records/{tableName}* ;
Re: [Architecture] BAM 3.0 REST APIs for AnalyticsDataService / Indexing / Search
Hi Gimantha, You haven't really replied to Sinthuja's points there. We have to decide if we are going ahead with Sinthuja's suggestions, or not. Lets first educate ourselves on the best practices of RESTful API design a bit, Googling helps [1]. For example, I'm also not sure if should be /analytics/{tableName}/records or /analytics/records/{tableName}, each has benefits, like, first approach can have ambiguity issues, specially when there other operations with optional fields. And also, I guess we will need to have /analytics/tables/{tableName} for creating tables etc.. or else, for example when we do a POST for like /analytics/T1, it may not be that informative what we are actually doing there. [1] https://www.google.com/search?q=REST+service+designgws_rd=ssl#q=REST+api+design Cheers, Anjana. On Wed, Jan 21, 2015 at 3:35 AM, Gimantha Bandara giman...@wso2.com wrote: Hi, Goood point!. Initially the search was implemented such a way that it returns a list of ids of records that match the query. Now the search method is changed, so it returns the records. So +1 for removing the API #6. @Sinduja, @Harshan Thanks for the reference links and for the feedback. On Tue, Jan 20, 2015 at 6:52 PM, Harshan Liyanage hars...@wso2.com wrote: Hi Gimantha, Could you please explain the use-case for the API #6? IMO there should not be any operation to fetch a list of records by ids. Instead there could be an API which sends a list of records as the response for a query. For the API #14 you can still use GET method with query strings. I think you have included start count parameters to control the pagination. For that you can use the HTTP range-header [1] or link headers as mentioned in [2]. [1]. http://otac0n.com/blog/2012/11/21/range-header-i-choose-you.html [2]. https://developer.github.com/v3/#pagination Regards, Lakshitha Harshan Software Engineer Mobile: *+94724423048* Email: hars...@wso2.com Blog : http://harshanliyanage.blogspot.com/ *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. On Tue, Jan 20, 2015 at 6:34 PM, Gimantha Bandara giman...@wso2.com wrote: Hi Harshan, Thanks for the feedback. The list of IDs of the records to be retrieved can be too long. So setting a list of ids as a query param is not convenient. Even for the Search, we have to pass a query, which can be too long. Thats why the post method is used for Search. Thanks, On Tue, Jan 20, 2015 at 12:52 PM, Sinthuja Ragendran sinth...@wso2.com wrote: Hi Gimantha, I think following the conventions will be more intuitive to the users, and we should have a proper reason to not follow. And the post request is generally needs to be sent to create the object and the back end is going to decide where to create the tables resource, therefore it should be POST to '/analytics/tables' and message body should be having the table name. If you want to use /analytics/{tableName}, then you should use PUT rather POST [1]. But IMO POST is the most suitable operation for this context. And through out the below given URL patterns, in order to fetch the records from a table, you have used '/analytics/records/{tableName}' url pattern where 'records' is in the middle and it is not the correct data hierarchy and again I feel it's not the convention. Basically tables contains records and not records contains tables. Therefore if we use POST to '/analytics/tables' for create table, then you can use simply user 'analytics/{tableName}' to GET/POST for the tables, IMHO the records is just an additional segment which is not needed to be here. [1] http://restcookbook.com/HTTP%20Methods/put-vs-post Thanks, Sinthuja. On Tue, Jan 20, 2015 at 1:29 AM, Gimantha Bandara giman...@wso2.com wrote: Hi Sinduja, Thank you for the feedback. On Mon, Jan 19, 2015 at 12:04 PM, Sinthuja Ragendran sinth...@wso2.com wrote: Hi gimantha, Please see the comments inline. On Sun, Jan 18, 2015 at 11:24 PM, Gimantha Bandara giman...@wso2.com wrote: Hi, Currently, I am working on $subject. Basically the methods in AnalyticsDataService will be exposed through REST APIs. Please refer to Architecture mail thread *[Architecture] BAM 3.0 Data Layer Implementation / RDBMS / Distributed Indexing / Search* for more Details. Following are the supported REST APIs. 1. Create a table *POST /analytics/{tableName}* ; tableName - The name of the table to be created. IMHO the above should be POST to '/analytics/*tables*' and the request content should have the table name as given below. { tableName : Test } Since the POST takes only the table name, it is straightforward to use it as a path parameter. 2. Delete a table *DELETE /analytics/{tableName} * ; tableName - The name of the table to be deleted. 3. Check if a table exists *GET /analytics/{tableName} * ; tableName - The name of the table being checked. 4. List All the tables *GET /analytics/tables* ;Response will be