Thanks all for the responses.
I will go ahead with option 1.
So with that,
- The rating value of the API *will not be returned* in the response of
the getAPI resource API.
- Separate resource APIs will be implemented to do the following.
- add rating value by an API
- get the overall rating of an API
- to get rating given by a particular
subscriber for an API
Thanks,
Chamalee.
On Thu, Mar 2, 2017 at 10:01 AM, Vidura Nanayakkara <[email protected]>
wrote:
> Hi Chamalee,
>
> The response in [1]
> <http://softwareengineering.stackexchange.com/questions/305872/many-asynchronous-calls-vs-single-call-to-the-api>
> suggests
> option 1 in general. It explains few good points that are worth looking at.
>
> Furthermore, in addition to Chamin's response, getAPI call looks to me is
> common HTTP call in the application. Therefore we do not need to include
> additional information in the response. (You only need to proceed with
> option 2 if you need to always get the API rating along with the API (a
> single request is much more scalable than multiple requests in this case))
>
> So IMO we should proceed with option 1
>
> [1] Many asynchronous calls vs single call to the API
> <http://softwareengineering.stackexchange.com/questions/305872/many-asynchronous-calls-vs-single-call-to-the-api>
>
>
> On Wed, Mar 1, 2017 at 6:09 PM, Malintha Amarasinghe <[email protected]>
> wrote:
>
>>
>>
>> On Wed, Mar 1, 2017 at 1:45 PM, Chamalee De Silva <[email protected]>
>> wrote:
>>
>>> Hi all,
>>>
>>> I am working on adding REST APIs for the following operations.
>>>
>>> 1. Rate an API (add rating)
>>> 2. Get rating of an API (given the UUID of the API)
>>>
>>>
>>> A separate table is going to be added to store for API_RATINGS like what
>>> we had in APIM 2.1.0
>>> where it has 1:m mapping with AM_API table.
>>>
>>> AM_API_RATINGS
>>>
>>> ID
>>>
>>> API_ID
>>>
>>> SUBSCRIBER_ID
>>>
>>> RATING
>>>
>>>
>>>
>>>
>>>
>>> In current implementation or in the previous version of the API there is
>>> no implementation to get the API rating when retrieving the API in Store
>>> REST API.
>>>
>>> We need to get the rating of the API at the same time we do the GET_API
>>> call when thinking of the UI perspective to display the API in Store.
>>>
>>> So there are two options available to get the rating of the API.
>>>
>>>
>>> *Option 1 : *
>>> Do the *getAPIRating *call (/apis/{apiId}/rating) right after the
>>> getAPI call.
>>>
>>> If we do this there will be t*wo REST calls* one after the
>>> other. But the query execution will be less expensive and less complex.
>>>
>> +1. Better to keep this outside of the API since this is not really a
>> part of the API resource. Adding to Chamin's and Harsha's comments; If we
>> make this as part of the API resource, we will always have to change the
>> ETag of the API once a user changes the rating of the API (which can happen
>> frequently compared to a change that happens to the actual API). This is an
>> unnecessary change that would affect client side caching. I think we need
>> to be bit careful about this when doing changes to any exising resource in
>> general.
>>
>> Thanks!
>> Malintha
>>
>>>
>>>
>>>
>>>
>>> *Option 2 : *
>>> Get the rating value of the particular API inside the same
>>> query for get_API , add it to the API object as a property and retrieve
>>> the rating with *getAPI* call.
>>>
>>> This will reduce it to one REST call to the server, but in
>>> DB level, we are doing a bit complex query
>>>
>>> e.g. Then the getAPI query will be like this with an inner
>>> join operation.
>>>
>>> *select *
>>> * a.id <http://a.id>, a.name
>>> <http://a.name>, a.context, ..... , avg(r.rating)*
>>> *from*
>>> * AM_API a*
>>> * inner join*
>>> * AM_RATING r ON a.ID = r.api_id*
>>> * GROUP BY a.name <http://a.name>,
>>> a.context, ..., ,..,..,*
>>> * WHERE a.id <http://a.id> = ? ;*
>>>
>>> * Option 3 : *
>>>
>>> To reduce the complexity of the query described in option 2,
>>> we can do execute two queries on the database.
>>>
>>> - First one to get the API from the AM_API table
>>> - Second query to get the average rating of that particular
>>> API.
>>>
>>> Then after adding the rating value as a property of the API
>>> object and retrieve with the *getAPI* call.
>>>
>>>
>>>
>>>
>>> From these two options what is the best way to implement ?
>>>
>>> Assume if we select option 3, then, should we still have option 1 to be
>>> used independently ?
>>>
>>> Appreciate your feedback on this.
>>>
>>>
>>>
>>> Thanks
>>> Chamalee
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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*
>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>
>
> --
> Best Regards,
>
> *Vidura Nanayakkara*
> Software Engineer
>
> Email : [email protected]
> Mobile : +94 (0) 717 919277 <+94%2071%20791%209277>
> Web : http://wso2.com
> Blog : https://medium.com/@viduran <http://wso2.com/>
> Twitter : http://twitter.com/viduranana
> LinkedIn : https://lk.linkedin.com/in/vidura-nanayakkara
> <http://wso2.com/>
>
--
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*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
