Hi Frank,
Got it. Thanks a lot.
Best Regards,
Lakshitha Harshan
Software Engineer
Mobile: *+94724423048*
Email: hars...@wso2.com
Blog : http://harshanliyanage.blogspot.com/
*WSO2, Inc. :** wso2.com http://wso2.com/*
lean.enterprise.middleware.
On Wed, Feb 18, 2015 at 5:58 PM, Frank Leymann
Hi Harshan,
Thank you for the reply. What if we do not provide an API to check if the
table exists or not, and user can use other APIs as usual. If the table
really does not exist, then he get the response saying the table doesn't
exist with the status code 403?
Thanks,
On Tue, Feb 17, 2015 at
Hi Gimantha,
I think Frank has explained everything about the usage of *GET
/analytics/tables/{tableName}*. Anyway what my point is that if we have
used *GET* */analytics/tables/{tableName} *to check the existence of the
table it would work nice if the table does not exist. But if the table
Hi Gimantha,
it depends on the scenario: if you want to check existence of resource
it's fine to use a GET on this resource and receive a 404 Not Found.
But the subtlety is that Not Found according to HTTP is statement in
time: you cannot infer that the resource does not exist, all that 404
Hi Frank,
Thanks you for your explanation!. What we currently do is, using *GET
/analytics/tables/{tableName} *get the whole table, if the table does not
exist, HTTP status will be 404 and the response body will have a message
saying that the table does not exist.
On Sun, Feb 15, 2015 at 9:03
Hi Manuranga,
Already *GET /analytics/tables/{tableName} *returns 404 if the
table doesn't exists. So we will not need a separate API. Thanks for your
feedback.
On Sat, Feb 14, 2015 at 12:22 PM, Manuranga Perera m...@wso2.com wrote:
there shouldn't be a separate end point for is-exists
*GET
@Roshan,
These APIs are tightly coupled with the product. If user wants to migrate
to a newer version, then the user has to use the newer APIs that come with
the new product version. We have started the separate mail thread to
discuss this.
@Harshan
Again *GET
there shouldn't be a separate end point for is-exists
*GET /analytics/tables/{tableName}* - Will return table informing if it
exists and if not it should return 404
___
Architecture mailing list
Architecture@wso2.org
Hi Gimantha,
Don't we need to maintain a version with an API?
Regards
Roshan
On Fri, Feb 13, 2015 at 3:08 AM, Gimantha Bandara giman...@wso2.com wrote:
Hi all,
I changed the APIs so they follow the convention and i tested if there are
conflicts between some APIs. JAX RS treats *GET
Hi Gimantha,
I think it's better if you could change the API #3 to something more
meaningful like *GET /analytics/tables/is-exists?tableName=table-name*.
When you have the following format for that API, it's more like you are
trying to fetch the table instead of checking for its existence. Anyway
Hi Harshan,
Thanks for the feedback. The list of IDs of the records to be retrieved can
be too long. So setting a list of ids as a query param is not convenient.
Even for the Search, we have to pass a query, which can be too long. Thats
why the post method is used for Search.
Thanks,
On Tue,
Hi Gimantha,
Could you please explain the use-case for the API #6? IMO there should not
be any operation to fetch a list of records by ids. Instead there could be
an API which sends a list of records as the response for a query.
For the API #14 you can still use GET method with query strings. I
Hi,
Goood point!. Initially the search was implemented such a way that it
returns a list of ids of records that match the query. Now the search
method is changed, so it returns the records. So +1 for removing the API
#6.
@Sinduja, @Harshan
Thanks for the reference links and for the feedback.
Hi Gimantha,
You haven't really replied to Sinthuja's points there. We have to decide if
we are going ahead with Sinthuja's suggestions, or not. Lets first educate
ourselves on the best practices of RESTful API design a bit, Googling helps
[1]. For example, I'm also not sure if should be
Hi Gimantha,
AFAIK when writing REST APIs you have use POST verb to create a resource
and the resource data should be sent as the POST request body. I totally
agree with Sinthuja's comment regarding url pattern of *POST
/analytics/{tableName}*.
IMO you should not use POST methods to the
Hi Gimantha,
I think following the conventions will be more intuitive to the users, and
we should have a proper reason to not follow. And the post request is
generally needs to be sent to create the object and the back end is going
to decide where to create the tables resource, therefore it
Hi Sinduja,
Thank you for the feedback.
On Mon, Jan 19, 2015 at 12:04 PM, Sinthuja Ragendran sinth...@wso2.com
wrote:
Hi gimantha,
Please see the comments inline.
On Sun, Jan 18, 2015 at 11:24 PM, Gimantha Bandara giman...@wso2.com
wrote:
Hi,
Currently, I am working on $subject.
Hi,
Currently, I am working on $subject. Basically the methods in
AnalyticsDataService will be exposed through REST APIs. Please refer to
Architecture mail thread *[Architecture] BAM 3.0 Data Layer Implementation
/ RDBMS / Distributed Indexing / Search* for more Details. Following are
the
Please note that the request content for No. 7 will take the following
format.
[
{
id: id1,
tableName: tableName1,
timestamp: -mm-dd hh:mm:ss,
values:
{
columnName1: value1,
columnName2: value2
}
},
{
19 matches
Mail list logo
