Re: [Architecture] [Dev] [REST APIs][Analytics] GET request with a payload
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 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
> 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" : ,
>>
>>
>> "fields: ["field1", field2", field3"]
>> }
>>
>>
>>
>>
>> On Thu, Mar 24, 2016 at 2:59 PM, Lahiru Sandaruwan
>> 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
>>> 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
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/
>
> {
> from:
> to:
> start:
> count:
> columns :[c1,c2,c3]
> }
>
> or
>
> POST /analytics/
>
> {
> 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
>> 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.
Re: [Architecture] [Dev] [REST APIs][Analytics] GET request with a payload
1) I agree that they are not resources. We were discussing whether to use
query parameters or a POST with those parameters. These APIs were already
released in DAS 3.0.0 and we cant change now. We will change the APIs
according to the REST guide in the next major release.
2) /analytics/search [1] is used to search the records with a given Lucene
query, in a specific table and pagination information. Those information is
sent in the POST payload. It doesnt support drilldown.
3) /analytics/drilldown[2] supports Lucene facet based drilldown + search.
Using that, we can retrieve records. Here also we cant use a GET, because
it has a lots of parameters in the request like, tablename, facet field
name, categorypath, pagination information, lucene query..etc
[1]
https://docs.wso2.com/display/DAS300/Retrieving+All+Records+Matching+the+Given+Search+Query+via+REST+API
[2]
https://docs.wso2.com/display/DAS300/Retrieving+Specific+Records+through+a+Drill+Down+Search+via+REST+API
On Fri, Apr 15, 2016 at 7:30 PM, Manuranga Perera wrote:
> 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
> 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
>> 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" : ,
>>>
>>>
>>> "fields: ["field1", field2", field3"]
>>> }
>>>
>>>
>>>
>>>
>>> On Thu, Mar 24, 2016 at 2:59 PM, Lahiru Sandaruwan
>>> 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
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
> 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/
>>
>> {
>> from:
>> to:
>> start:
>> count:
>> columns :[c1,c2,c3]
>> }
>>
>> or
>>
>> POST /analytics/
>>
>> {
>> 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
Re: [Architecture] [Dev] [REST APIs][Analytics] GET request with a payload
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 :
> 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
> 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
>> 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" : ,
>>>
>>>
>>> "fields: ["field1", field2", field3"]
>>> }
>>>
>>>
>>>
>>>
>>> On Thu, Mar 24, 2016 at 2:59 PM, Lahiru Sandaruwan
>>> 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
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
> 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/
>>
>> {
>> from:
>> to:
>> start:
>> count:
>> columns :[c1,c2,c3]
>> }
>>
>> or
>>
>> POST /analytics/
>>
>> {
>> 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 >> > 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
gi
Re: [Architecture] [Dev] [REST APIs][Analytics] GET request with a payload
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 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 :
>
>> 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
>> 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
>>> 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" : ,
"fields: ["field1", field2", field3"]
}
On Thu, Mar 24, 2016 at 2:59 PM, Lahiru Sandaruwan
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
> 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
>> 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/
>>>
>>> {
>>> from:
>>> to:
>>> start:
>>> count:
>>> columns :[c1,c2,c3]
>>> }
>>>
>>> or
>>>
>>> POST /analytics/
>>>
>>> {
>>> 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.
>>>
Re: [Architecture] [Dev] [REST APIs][Analytics] GET request with a payload
Ah, now I got it! Thanks!
Best regards,
Frank
2016-04-15 19:34 GMT+02:00 Gimantha Bandara :
> 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 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 :
>>
>>> 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
>>> 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
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" : ,
>
>
> "fields: ["field1", field2", field3"]
> }
>
>
>
>
> On Thu, Mar 24, 2016 at 2:59 PM, Lahiru Sandaruwan
> 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
>> 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 >> > 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/
{
from:
to:
start:
count:
columns :[c1,c2,c3]
}
or
POST /analytics/
{
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 Gima
