Hi Fazlan,
There is no special reason to follow that other than the one I mentioned
above as the problematic situation. Are you suggesting PUT and POST for the
same resource for creating and updating?
Eg:
POST /apis/{apiId}/rating - to add a rating
PUT /apis/{apiId}/rating - to update a rating
If we follow the above traditional approach, we need to make sure that POST
can be only executed once (i.e we need to write it in the code). If someone
needs to update the rating, he should then use PUT instead of POST.
I think this is an additional burden to the client as well as the one who
writes the server code as he needs to duplicate code and also do redundant
validations (make only first POST valid and next POSTs should fail, first
PUT without a POST should fail and etc). So this was the reason to keep
only one verb (POST) to add and update that particular resource.
However, If we are using a single verb, I feel that the most suitable verb
should be PUT not POST [1]. According to the spec, PUT can be used to both
create and update [2].
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. *If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified version of
the one residing on the origin server. If the Request-URI does not point to
an existing resource, and that URI is capable of being defined as a new
resource by the requesting user agent, the origin server can create the
resource with that URI*. If a new resource is created, the origin server
MUST inform the user agent via the 201 (Created) response.
WDYT?
Hi Joe,
Appreciate your thoughts on this..
Thanks!
Malintha
[1] http://stackoverflow.com/questions/630453/put-vs-post-in-rest
[2] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
On Mon, Apr 3, 2017 at 7:30 PM, Fazlan Nazeem <[email protected]> wrote:
> Hi Malintha,
>
> On Mon, Apr 3, 2017 at 5:28 PM, Malintha Amarasinghe <[email protected]>
> wrote:
>
>> Hi,
>>
>> UPDATED_BY is an Audit column which is included every resource table
>> regardless of their business logic. Comments are one type of resource.
>>
>> CREATED_TIME, CREATED_BY, LAST_UPDATED_TIME and UPDATED_BY are those
>> columns we use for audit purpose which we include in every resource table
>> like APIs, Application, Policy and etc.
>>
>> Regarding Fazlan's comment, I think we need to discuss and fix. We have
>> the same situation in POST /apis/{apiId}/thumbnail as well where we use
>> POST for both first-time addition and update thereafter. However keeping a
>> POST which can be executed only once is also not a very good solution IMO
>> which makes an additional complexity for the client (who need to make sure
>> he should do the first call using a POST and thereafter do PUT for the same
>> resource).
>>
>
> Any reason for following this approach only to thumbnail and ratings?
>
>>
>> Thanks!
>>
>> On Mon, Apr 3, 2017 at 5:09 PM, Anuruddha Liyanarachchi <
>> [email protected]> wrote:
>>
>>> Hi Chamalee,
>>>
>>> Why do we have UPDATED_BY column? Do we allow users to update other
>>> users comments?
>>> IMO this should not be allowed.
>>>
>>> Allowing admin users to delete comments/ratings is ok, but we shouldn't
>>> allow them to edit.
>>>
>>> WDYT?
>>>
>>> On Mon, Apr 3, 2017 at 3:08 PM, Fazlan Nazeem <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Mon, Apr 3, 2017 at 2:08 PM, Chamalee De Silva <[email protected]>
>>>> wrote:
>>>>
>>>>> hi all,
>>>>> Ratings and Comments impact on the impression of the API Store users
>>>>> of the APIs published in the API Store.
>>>>> The popularity, importance of the API, the pros and cons of the API
>>>>> can be evaluated through the Ratings and Comments given to the APIs.
>>>>>
>>>>> To achieve that in APIM 3.0.0, following REST APIs are identified to
>>>>> be implemented.
>>>>>
>>>>>
>>>>> *Ratings :*
>>>>>
>>>>> 1. Retrieve the average rating of the API, rating given by the logged
>>>>> in user and the rating list. (A composite list will be retrieved as the
>>>>> response.)
>>>>> 3. Adding a new rating to an API (Updating the existing rating will
>>>>> also be handled through this.)
>>>>>
>>>>> Does this mean we handle both operations using same API operation? If
>>>> so we have to send a POST request to an update operation. That doesn't
>>>> sound right. We have to have two operations for adding(POST) and
>>>> update(PUT) the rating. Any explanation?
>>>>
>>>> *Comments :*
>>>>>
>>>>> 1. Retrieve the list of Comments of an API
>>>>> 2. Retrieve an individual Comment of an API
>>>>> 3. Add a new Comment to an API
>>>>> 4. Update an existing Comment of an API
>>>>> 5. Delete a particular Comment
>>>>>
>>>>> Database schema is updated with adding two tables as follows.
>>>>>
>>>>> AM_API_RATINGS
>>>>>
>>>>> RATING_ID
>>>>>
>>>>> API_ID
>>>>>
>>>>> RATING
>>>>>
>>>>> USER_IDENTIFIER
>>>>>
>>>>> CREATED_BY
>>>>>
>>>>> CREATED_TIME
>>>>>
>>>>> UPDATED_BY
>>>>>
>>>>> LAST_UPDATED_TIME
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> AM_API_COMMENTS
>>>>>
>>>>> COMMENT_ID
>>>>>
>>>>> API_ID
>>>>>
>>>>> COMMENT_TEXT
>>>>>
>>>>> USER_IDENTIFIER
>>>>>
>>>>> CREATED_BY
>>>>>
>>>>> CREATED_TIME
>>>>>
>>>>> UPDATED_BY
>>>>>
>>>>> LAST_UPDATED_TIME
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The COMMENT_ID and API_ID are UUIDs which are primary keys.
>>>>>
>>>>>
>>>>> These are further described as user stories in redmine [1] under Epic
>>>>> #5963 <https://redmine.wso2.com/issues/5963>
>>>>> and the public JIRA can be found at -[2].
>>>>>
>>>>> We have done a design review for this and please find the design
>>>>> review comments in [3].
>>>>>
>>>>> The REST API definition and schema level implementation is
>>>>> complemented and following are left to be completed in this feature.
>>>>>
>>>>> 1. DAO level implementation for retrieving and storing values.
>>>>> 2. Permission model considerations
>>>>> - As we discussed within the team, to rate an API or to
>>>>> Comment an API, the user should have* at least* the permission to
>>>>> view the API. He should have the API_ID in hand to manipulate all REST
>>>>> APIs which goes under Ratings and Comments.
>>>>> Assuming that permission check for API is happening prior
>>>>> to every operation we are safe in that side.
>>>>>
>>>>> 3. Other than that, as discussed in the design review we should
>>>>> calculate the average rating of each of the API using a separate
>>>>> Database operation and set the rating to the APIInfo object where we
>>>>> do the listAllAPIs call as well.
>>>>> (For per API scenario, We are going to use a separate REST call as
>>>>> per in discussion [4])
>>>>>
>>>>>
>>>>>
>>>>> [1] https://redmine.wso2.com/issues/5963
>>>>> [2] <https://github.com/wso2/carbon-apimgt/pull/3879>
>>>>> https://wso2.org/jira/browse/APIMANAGER-5684
>>>>> <https://www.google.com/url?q=https%3A%2F%2Fwso2.org%2Fjira%2Fbrowse%2FAPIMANAGER-5684&sa=D&sntz=1&usg=AFQjCNEKLLoVtUwWONla9d_Gw8FD6iVdlQ>
>>>>> [3] Updated Invitation: [APIM][C5][Design Review] REST APIs for
>>>>> Rating and Commen... @ Tue Mar 28, 2017 12pm - 12:45pm (IST) (WSO2
>>>>> Engineering Group)
>>>>> [4] Retrieving Rating value of API in the GET_API resource API
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks & Regards,
>>>>>
>>>>> *Chamalee De Silva*
>>>>> Software Engineer
>>>>> *WS**O2* Inc. :http://wso2.com/
>>>>>
>>>>> Office :- *+94 11 2145345 <%2B94%2011%202145345>*
>>>>> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks & Regards,
>>>>>
>>>>> *Chamalee De Silva*
>>>>> Software Engineer
>>>>> *WS**O2* Inc. :http://wso2.com/
>>>>>
>>>>> Office :- *+94 11 2145345 <%2B94%2011%202145345>*
>>>>> mobile :- *+94 7 <%2B94%2077%202782039>1 4315942*
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks & Regards,
>>>>
>>>> Fazlan Nazeem
>>>>
>>>> *Senior Software Engineer*
>>>>
>>>> *WSO2 Inc*
>>>> Mobile : +94772338839
>>>> <%2B94%20%280%29%20773%20451194>
>>>> [email protected]
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Thanks and Regards,*
>>> Anuruddha Lanka Liyanarachchi
>>> Software Engineer - WSO2
>>> Mobile : +94 (0) 712762611
>>> Tel : +94 112 145 345
>>> a <[email protected]>[email protected]
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Malintha Amarasinghe
>> Software Engineer
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Thanks & Regards,
>
> Fazlan Nazeem
>
> *Senior Software Engineer*
>
> *WSO2 Inc*
> Mobile : +94772338839
> <%2B94%20%280%29%20773%20451194>
> [email protected]
>
--
Malintha Amarasinghe
Software Engineer
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/
Mobile : +94 712383306
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
