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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
