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
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]
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
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
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
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
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:
Agreed. Then again, if user needs to include more columns than he needs to
exclude we can introduce something like below and use the most suitable
depending on the length.
service?*include*=column1,column2*- only include columns specified by
user*
service?*exclude*=column1,column2 *-
Hi,
IMO by using POST to do a GET we are violating REST principals and may
confuse users. You can see a query type API in [1] used by StackOverflow
API. According to [2], it seems about 2000 characters are allowed most
browsers which is a pretty large number where a normal GET request is
Thank you for your suggestions.
We cannot exactly say that the number of columns/fields user will need. It
depends on how many fields a table has and how many the user want to get
from that table. So the url length might exceed. If so, we will have to go
with a new method with POST as it seems the
Yes, if it is possible to put the columns names in the url as Ayoma
mentioned, we must use that(First i thought it is a complex payload you
want to send).
Unless there are limitations, like column list doesn't exceed the url
length limits, we should use GET.
Thanks.
On Wed, Mar 23, 2016 at 3:54
Hi,
It is true that using GET request with a payload is not the best option.
Even though it is not strictly prohibited in specs, it can be confusing
[1]. REST architecture is very open about how we use HTTP methods, but
thinking in terms of REST architecture, I do not think using POST is also
the
Hi,
I think using a POST with a body, for retrieving information is fine
considering the requirement. GET with body is not recommended.
Thanks.
On Wed, Mar 23, 2016 at 2:31 PM, Gimantha Bandara wrote:
> Hi all,
>
>
> We have a REST API in DAS to retrieve records in a
13 matches
Mail list logo