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
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev