Agreed. Then again, if user needs to include more columns than he needs to exclude we can introduce something like below and use the most suitable depending on the length.
service?*include*=column1,column2 *- only include columns specified by user* service?*exclude*=column1,column2 *- include all columns, excluding what is provided by user* Then again, there are even lower level limitations such as InnoDB limit on maximum 1000 columns [2]. If we really have such as use case where this list can grow more than 2000 characters, maybe it is best to use POST only for such abnormal scenarios. [1] http://stackoverflow.com/questions/15090220/maximum-length-for-url-in-chrome-browser [2] http://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html On Thu, Mar 24, 2016 at 12:03 PM, Udara Liyanage <ud...@wso2.com> wrote: > Hi, > > IMO by using POST to do a GET we are violating REST principals and may > confuse users. You can see a query type API in [1] used by StackOverflow > API. According to [2], it seems about 2000 characters are allowed most > browsers which is a pretty large number where a normal GET request is > highly unlikely to exceed in practical situation regardless of the number > of fields exist. > > > [1] https://api.stackexchange.com/docs/users > [2] > http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers > > On Thu, Mar 24, 2016 at 11:38 AM, Gimantha Bandara <giman...@wso2.com> > wrote: > >> Thank you for your suggestions. >> We cannot exactly say that the number of columns/fields user will need. >> It depends on how many fields a table has and how many the user want to get >> from that table. So the url length might exceed. If so, we will have to go >> with a new method with POST as it seems the only option. >> >> On Wed, Mar 23, 2016 at 9:34 PM, Lahiru Sandaruwan <lahi...@wso2.com> >> wrote: >> >>> Yes, if it is possible to put the columns names in the url as Ayoma >>> mentioned, we must use that(First i thought it is a complex payload you >>> want to send). >>> >>> Unless there are limitations, like column list doesn't exceed the url >>> length limits, we should use GET. >>> >>> Thanks. >>> >>> On Wed, Mar 23, 2016 at 3:54 PM, Ayoma Wijethunga <ay...@wso2.com> >>> wrote: >>> >>>> Hi, >>>> >>>> It is true that using GET request with a payload is not the best >>>> option. Even though it is not strictly prohibited in specs, it can be >>>> confusing [1]. REST architecture is very open about how we use HTTP >>>> methods, but thinking in terms of REST architecture, I do not think using >>>> POST is also the correct approach here [2] (maybe it is just the personal >>>> preference). >>>> >>>> Let me summaries few examples on how others have addressed the same >>>> requirement with GET requests. >>>> >>>> Facebook Graph API is using "field" query parameter for this [3]. For >>>> example : >>>> >>>> Following Graph API call >>>> *https://graph.facebook.com/bgolub?fields=id,name,picture >>>>> <https://graph.facebook.com/bgolub?fields=id,name,picture>* will only >>>>> return the id, name, and picture in Ben's profile >>>>> >>>> >>>> SharePoint syntax is not very eye candy [4][5], but it goes like : >>>> >>>> >>>>> http://server/siteurl/_vti_bin/listdata.svc/DocumentsOne?$select=MyDocumentType,Title,Id&$expand=MyDocumentType >>>>> >>>> >>>> YouTube API has the same in below form [6] : >>>> >>>> Example 1: Retrieve number of items in feed, index of >>>>> first item in result set, and all entries in the feed: >>>>> fields=openSearch:totalResults,openSearch:startIndex,entry >>>>> >>>> >>>> LinkedIn has the same [7] >>>> >>>> >>>>> https://api.linkedin.com/v1/people-search:(people:(id,first-name,last-name,positions:(id,title,summary,start-date,end-date,is-current,company:(id,name,type,size,industry,ticker)) >>>>> >>>> >>>> IMO Facebook Graph API has the cleanest mechanism. >>>> >>>> I believe that if we use a similar format we will not have to introduce >>>> new resource paths. Instead we'll be able to provide all the columns, >>>> unless user specifically request limited set of fields with a query >>>> parameter. WDYT? >>>> >>>> [1] >>>> http://stackoverflow.com/questions/5216567/is-this-statement-correct-http-get-method-always-has-no-message-body >>>> [2] https://spring.io/understanding/REST >>>> [3] >>>> https://developers.facebook.com/docs/graph-api/using-graph-api#fieldexpansion >>>> [4] >>>> http://sharepoint.stackexchange.com/questions/118633/how-to-select-and-filter-list-items-lookup-column-with-sharepoint-2013-rest-feat >>>> [5] >>>> http://platinumdogs.me/2013/03/14/sharepoint-adventures-with-the-rest-api-part-1/ >>>> [6] >>>> https://developers.google.com/youtube/2.0/developers_guide_protocol_partial#Fields_Formatting_Rules >>>> [7] https://developer.linkedin.com/docs/fields?u=0 >>>> >>>> Best Regards, >>>> Ayoma. >>>> >>>> On Wed, Mar 23, 2016 at 8:13 PM, Lahiru Sandaruwan <lahi...@wso2.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I think using a POST with a body, for retrieving information is fine >>>>> considering the requirement. GET with body is not recommended. >>>>> >>>>> Thanks. >>>>> >>>>> On Wed, Mar 23, 2016 at 2:31 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ayoma Wijethunga >>>> Software Engineer >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> Mobile : +94 (0) 719428123 <+94+(0)+719428123> >>>> Blog : http://www.ayomaonline.com >>>> LinkedIn: https://www.linkedin.com/in/ayoma >>>> >>> >>> >>> >>> -- >>> -- >>> 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 >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> architect...@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> 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 >> >> > > > -- > > Udara Liyanage > Software Engineer > WSO2, Inc.: http://wso2.com > lean. enterprise. middleware > > web: http://udaraliyanage.wordpress.com > phone: +94 71 443 6897 > > _______________________________________________ > Architecture mailing list > architect...@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Ayoma Wijethunga Software Engineer WSO2, Inc.; http://wso2.com lean.enterprise.middleware Mobile : +94 (0) 719428123 <+94+(0)+719428123> Blog : http://www.ayomaonline.com LinkedIn: https://www.linkedin.com/in/ayoma
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
