Ah, now I got it! Thanks!
Best regards, Frank 2016-04-15 19:34 GMT+02:00 Gimantha Bandara <[email protected]>: > Hi Frank, > > Yes, I saw that and I read the document and it is very helpful. These APIs > were created and released last year. So we cannot change these APIs until > we do a major release. Of course the new changes in these REST APIs and new > REST APIs will be created adhering to those REST API Guidelines. > > On Fri, Apr 15, 2016 at 10:54 PM, Frank Leymann <[email protected]> wrote: > >> We built a REST API Guideline document a few weeks ago. Do you >> (Gimantha) see that? Its purpose is to help in designing REST APIs. If >> you think it would be helpful for you and your team, we can set up a call >> on this.... >> >> >> Best regards, >> Frank >> >> 2016-04-15 16:00 GMT+02:00 Manuranga Perera <[email protected]>: >> >>> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected] >>>>>>> > 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 < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> 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 >>>>>>>>>> [email protected] >>>>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> 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 >>>>>>> [email protected] >>>>>>> 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: [email protected] blog: http://lahiruwrites.blogspot.com/ >>>>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> 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 >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : [email protected] >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Gimantha Bandara > Software Engineer > WSO2. Inc : http://wso2.com > Mobile : +94714961919 >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
