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
