1) I agree that they are not resources. We were discussing whether to use query parameters or a POST with those parameters. These APIs were already released in DAS 3.0.0 and we cant change now. We will change the APIs according to the REST guide in the next major release.
2) /analytics/search [1] is used to search the records with a given Lucene query, in a specific table and pagination information. Those information is sent in the POST payload. It doesnt support drilldown. 3) /analytics/drilldown[2] supports Lucene facet based drilldown + search. Using that, we can retrieve records. Here also we cant use a GET, because it has a lots of parameters in the request like, tablename, facet field name, categorypath, pagination information, lucene query..etc [1] https://docs.wso2.com/display/DAS300/Retrieving+All+Records+Matching+the+Given+Search+Query+via+REST+API [2] https://docs.wso2.com/display/DAS300/Retrieving+Specific+Records+through+a+Drill+Down+Search+via+REST+API On Fri, Apr 15, 2016 at 7:30 PM, Manuranga Perera <m...@wso2.com> wrote: > 1) So {to}, {from}, {start}, {count} are resources ? They are not. How is > this REST? > 2) What are you searching in POST /analytics/search. > tables, drilldown, everything? I can't see that in URL. > 3) is POST /analytics/drilldown creating a drilldown or getting one ? If > it's getting one, this is also wrong, should be get. If creating, why not > PUT? > > > > > On Mon, Apr 4, 2016 at 12:08 AM, Gimantha Bandara <giman...@wso2.com> > wrote: > >> Please note that "fields" is changed to "columns" for consistency as in >> APIs, "columns" is used. >> >> On Mon, Apr 4, 2016 at 9:08 AM, Gimantha Bandara <giman...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> Thank you for your suggestions! We are going to use GET with the query >>> parameter "columns" to get the records filtered by a time range. So when >>> only a selected set of columns/fields are needed, Following format can be >>> used. >>> >>> *Get the records within a specific time range.* >>> >>> GET >>> /analytics/tables/{tableName}/{to}/{from}/{start}/{count}?fields=field1,field2,field3 >>> >>> *Drilldown and Search APIs* >>> >>> Additional JSON element will be added as following >>> >>> POST /analytics/drilldown or POST /analytics/search >>> >>> { >>> "tableName" : <tableName>, >>> .... >>> .... >>> "fields: ["field1", field2", field3"] >>> } >>> >>> >>> >>> >>> On Thu, Mar 24, 2016 at 2:59 PM, Lahiru Sandaruwan <lahi...@wso2.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> POST for filterings is not an issue for special cases, as document also >>>> clearly confirms. >>>> >>>> However, I think the decision has to be made on practical use cases. >>>> This use case doesn't looks like a complex one. As Ayoma mention, it is a >>>> good idea to implement two filters to include and exclude. >>>> >>>> Considering the practical use, if url length is not a problem(i.e. >>>> practically user will not have a requirement to use around 400 columns per >>>> search, if we average word length to 5), we should go for GET. >>>> >>>> Otherwise, we can go for POST. >>>> >>>> Thanks. >>>> >>>> On Thu, Mar 24, 2016 at 9:01 AM, Sachith Withana <sach...@wso2.com> >>>> wrote: >>>> >>>>> Hi Gimantha, >>>>> >>>>> I think the point made by Udara is valid. >>>>> Anyways if the user wants to get a selected number of columns, the >>>>> chances are it won't exceed the url limit. >>>>> ( due to the that number being low). >>>>> >>>>> Thanks, >>>>> Sachith >>>>> >>>>> On Thu, Mar 24, 2016 at 2:21 PM, Gimantha Bandara <giman...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi Sanjeewa, >>>>>> >>>>>> Thank you for the guidelines doc. The exact problem is discussed in >>>>>> 10.2 in the above document. We will be filtering the record values in >>>>>> each >>>>>> records by providing the required columns, so only those column values >>>>>> will >>>>>> be returned with each record. According to the document the POST can be >>>>>> used either for updating/creating a resource or for initializing a >>>>>> processing function. In our case we will be simply retrieving records but >>>>>> need to provide a filter for the record values. So from users >>>>>> perspective, >>>>>> it will be doing some processing and returning filtered records. >>>>>> >>>>>> We can actually implement the following url, but we cannot exactly >>>>>> say if it will exceed the url length limit. >>>>>> GET /analytics/tables/{tableName}?columns=column1,column2] >>>>>> >>>>>> Or we can implement something like below, >>>>>> >>>>>> POST /analytics/tables/tableName/<range-search> >>>>>> >>>>>> { >>>>>> from: >>>>>> to: >>>>>> start: >>>>>> count: >>>>>> columns :[c1,c2,c3] >>>>>> } >>>>>> >>>>>> or >>>>>> >>>>>> POST /analytics/<range-search> >>>>>> >>>>>> { >>>>>> tableName : >>>>>> from: >>>>>> to: >>>>>> start: >>>>>> count: >>>>>> columns :[c1,c2,c3] >>>>>> } >>>>>> >>>>>> Considering the url length limit, I think the second option is >>>>>> better. WDYT? >>>>>> >>>>>> On Thu, Mar 24, 2016 at 12:33 PM, Sanjeewa Malalgoda < >>>>>> sanje...@wso2.com> wrote: >>>>>> >>>>>>> Hi Gimantha, >>>>>>> Did you refer REST API guidelines document attached in this mail[1] >>>>>>> in architecture mailing list. >>>>>>> When we develop REST APIs please follow that document and if you see >>>>>>> anything missed there please let us know. >>>>>>> >>>>>>> [1][Architecture] REST API Guidelines >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> sanjeewa. >>>>>>> >>>>>>> On Wed, Mar 23, 2016 at 8:01 PM, Gimantha Bandara <giman...@wso2.com >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> We have a REST API in DAS to retrieve records in a specific table. >>>>>>>> It supports GET method with the following url format. >>>>>>>> >>>>>>>> /analytics/tables/{tableName}/{from}/{to}/{start}/{count} >>>>>>>> >>>>>>>> Sending a GET request to above url will give the records between >>>>>>>> given "from", "to" time range starting from index "start" with "count" >>>>>>>> page size. >>>>>>>> >>>>>>>> Now we need to change the API, so that the user can define the >>>>>>>> record columns/fields he wants. Current API will return the records >>>>>>>> with >>>>>>>> all the values/columns. To do that, we can allow the user to define the >>>>>>>> columns he needs, in the payload. But it seems that having a payload >>>>>>>> with a >>>>>>>> GET is not the convention/the best practice. >>>>>>>> >>>>>>>> POST can be used to send the column names as a payload, but here we >>>>>>>> are not making any updates to {tableName} resource. We will be just >>>>>>>> retrieving records using a POST. So it also seems not the >>>>>>>> convention/the >>>>>>>> best practice. >>>>>>>> >>>>>>>> The only solution I can think of is, having a different resource >>>>>>>> path to get the records with only specified fields/columns. Are there >>>>>>>> any >>>>>>>> other solutions? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Gimantha >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> Dev@wso2.org >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Sanjeewa Malalgoda* >>>>>>> WSO2 Inc. >>>>>>> Mobile : +94713068779 >>>>>>> >>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Gimantha Bandara >>>>>> Software Engineer >>>>>> WSO2. Inc : http://wso2.com >>>>>> Mobile : +94714961919 >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> architect...@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sachith Withana >>>>> Software Engineer; WSO2 Inc.; http://wso2.com >>>>> E-mail: sachith AT wso2.com >>>>> M: +94715518127 >>>>> Linked-In: <http://goog_416592669> >>>>> https://lk.linkedin.com/in/sachithwithana >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> architect...@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> -- >>>> Lahiru Sandaruwan >>>> Committer and PMC member, Apache Stratos, >>>> Senior Software Engineer, >>>> WSO2 Inc., http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> phone: +94773325954 >>>> email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/ >>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Gimantha Bandara >>> Software Engineer >>> WSO2. Inc : http://wso2.com >>> Mobile : +94714961919 >>> >> >> >> >> -- >> Gimantha Bandara >> Software Engineer >> WSO2. Inc : http://wso2.com >> Mobile : +94714961919 >> >> _______________________________________________ >> Architecture mailing list >> architect...@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : m...@wso2.com > -- Gimantha Bandara Software Engineer WSO2. Inc : http://wso2.com Mobile : +94714961919
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
