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