Ah, now I got it! Thanks!

Best regards,
Frank

2016-04-15 19:34 GMT+02:00 Gimantha Bandara <giman...@wso2.com>:

> Hi Frank,
>
> Yes, I saw that and I read the document and it is very helpful. These APIs
> were created and released last year. So we cannot change these APIs until
> we do a major release. Of course the new changes in these REST APIs and new
> REST APIs will be created adhering to those REST API Guidelines.
>
> On Fri, Apr 15, 2016 at 10:54 PM, Frank Leymann <fr...@wso2.com> wrote:
>
>> We built a REST API Guideline document a few weeks ago.  Do you
>> (Gimantha) see that?  Its purpose is to help in designing REST APIs.  If
>> you think it would be helpful for you and your team, we can set up a call
>> on this....
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-04-15 16:00 GMT+02:00 Manuranga Perera <m...@wso2.com>:
>>
>>> 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
>>>>>>>>>> d...@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
>>>>>>>> Architecture@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
>>>>>>> Architecture@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
>>>>>> d...@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
>>>> Architecture@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
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to