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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
