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
