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 <giman...@wso2.com> 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 <giman...@wso2.com>
> 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 <lahi...@wso2.com>
>> 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 <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
>>>
>>>
>>
>>
>> --
>> 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
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
With regards,
*Manu*ranga Perera.
phone : 071 7 70 20 50
mail : m...@wso2.com
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
