+1 to Option 1, an APIs ratings are not something that everyone will be interested in. Those who want that data can make the additional API call to retrieve it.
On 6 March 2017 at 13:40, Chamalee De Silva <[email protected]> wrote: > Hi Dilan, > > I agree with your point in terms of performance point of view. > But when thinking of implementing the retrieval of Rating value of an API > in terms of re-usability in scenarios like API composition which we are > going to implement in the future I think it is fair to have this as a > separate REST API. > > So far in the the current implementation of API Manager 3.0.0 all the > details of the API is taken from one single table. > With option 2, we are going to do an inner join of two tables to get the > rating value of the API. > > But in the future, same as for API Ratings we will need this > implementation to be done for API comments as well. > So in that case also we will need to change the getAPI query if we stick > with option 2. > > So if we go with option 2, I feel that we are making that query more > complex to get that data. > ( There can emerge some point where performance degradation due to this > expensive joining operations as well. Since we cannot predict whether we > can limit it with one inner join operation and how much data it can exist.) > > I am just explaining my opinion here. Please correct me if I am wrong. > > @all, > And really appreciate your ideas and feedback on this. > > > > Thanks, > Chamalee > > > > On Mon, Mar 6, 2017 at 12:28 PM, Dilan Udara Ariyaratne <[email protected]> > wrote: > >> Hi Chamalee, >> >> I think that the 1st option would be the slowest in performance as it >> requires two network calls to APIs + two separate DB Calls to get all >> information related to an API. >> >> So, IMO, we should rather focus on other two options which only require >> one network call, instead of the first. >> >> From that, 2nd option only involves 1 network call + 1 database call >> where as >> 3rd involves 1 network call + 2 database calls. >> >> So, IMO, what's left here to compare is if one join is better than >> performing multiple queries to achieve the same. >> >> Since you are performing simply an inner join here and not any outer join >> which can result in any redundant rows, I guess that 2nd option would be >> much better. >> >> WDYT? >> >> Thanks. >> >> *Dilan U. Ariyaratne* >> Senior Software Engineer >> WSO2 Inc. <http://wso2.com/> >> Mobile: +94766405580 <%2B94766405580> >> lean . enterprise . middleware >> >> >> On Fri, Mar 3, 2017 at 10:37 AM, Chamalee De Silva <[email protected]> >> wrote: >> >>> 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 >>> >>> >> > > > -- > 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 > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
