On Tue, Aug 9, 2016 at 2:26 PM, Malintha Amarasinghe <[email protected]> wrote:
> Hi Sineth, > > We cannot use ESB's cache mediator directly in REST API as it is a > completely different context (Cache mediator is used in Synapse Gateway > level and REST API is based on Apache CXF which is a web application). But > we can look into its implementation and see how it's done. > > It seems in Spring level there's some inbuilt support for ETags as well ( > ShallowEtagHeaderFilter) [1,2] which might worth to try. AFAIU what it > does is hashes the response and matches with the ETag sent by the user with > the ETag header. > > In our REST API architecture there are 3 main components. > > (1) Client > (2) REST API webapp > (3) API Manager Implementation based components > > Few cents from me I would think of the ways we can implement this ( I > think this is similar to "Server Side cache" as Sanjeewa mentioned) > > 1. Caching between Client <--> REST API Webapp only. > a. Client(1) sends a GET request with the If-None-Match header and the > resource ID which he want to see. > b. Webapp(2) fetches the request using the Id of the resource from the > Implementation Components (3) > c. Webapp (2) generates the hash for the resource > d. If the ETag sent by the client and the generated ETag matches, Webapp > sends the response with 304 Not Modified > > This way, clearly we can reduce the traffic between the Client and the > webapp. But the webapp still requires to fetch the resource always by > talking to the APIM Implementation level. For me it seems this is similar > to [1]. > > 2. Caching between both Client <--> REST API Webapp and REST API Webapp > <--> APIM Implementation components > a. Client(1) sends a GET request with the If-None-Match header and the > resource ID which he want to see. > b. Webapp(2) find it **somehow** that the resource is not modified in the > server without feting it from the Implementation Components (3) > c. Webapp sends the response with 304 Not Modified > > I think this is the best if we can do as this reduces the traffic between > the client and REST API and also reduces the load for the API Manager Impl > Components as well. > In REST, we know only PUT/POST and DELETE can cause a > modification/deletion for a particular resource, which in turn modifies the > existing ETag (or remove it). If there's no POST/PUT/DELETE happened to a > particular resource can't REST API think that there's no change happened to > the particular resource? We might be able to get some help from this > concept to implement caching this way.. > > In this case we need to assume that none of the Resources are modified other than from the REST API. Once we completely moved to the REST API, the new UIs will also use that so that won't be a problem. But someone can still modify things in the Databases, Registry manually which is rare. > Thanks, > Malintha > > [1] http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/ > springframework/web/filter/ShallowEtagHeaderFilter.html > [2] https://www.javacodegeeks.com/2013/01/etags-for-rest-with-spring.html > > > On Tue, Aug 9, 2016 at 12:14 PM, Sineth Jayasinghe <[email protected]> > wrote: > >> Dear Sanjeewa, >> Thanks for the quick response, as far as the APIM documentation goes, we >> already have some form of caching for resources and other stuff, and i >> quote from the APIM documentation itself >> "The API Manager uses WSO2 ESB's cache mediator >> <http://docs.wso2.org/enterprise-service-bus/Cache+Mediator> to cache >> response >> messages per each API.". if this is the case, >> is there any downside of using the ESB's cache mediator?? >> Should we be building a brand new cache manager from scratch instead of >> improving the current cache mediator? >> >> On Tue, Aug 9, 2016 at 11:42 AM, Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> Hi All, >>> Richardson Maturity Model level 3 is more about HATEOAS (Hypertext As >>> The Engine Of Application State) and self descriptive APIs. >>> I don't see direct relationship with caching/concurrency control with >>> level 3. >>> And we don't have immediate plan to support level 3 and if we consider >>> other software organizations we do see users are moving towards level 3. >>> Most of them are stop at level 2. >>> >>> But http cache and concurrency controlling headers such as E-Tag will >>> definitely add value to our API even if we are at level 2. So IMO no need >>> to focus on all aspects of level 3 but we can add caching and concurrency >>> control on top of what we have now. >>> For the caching usually following 3 topologies will be used. >>> >>> - Client-side cache >>> - Server-side cache >>> - Separate component >>> >>> If we need to implement server side cache then we may need to do some >>> work with REST API. We can consider different approaches for that. >>> 01. Implement caching layer within API. If we consider this then cache >>> will bind to server itself. >>> 02. Implement caching and concurrency control layer as CXF interceptor. >>> If we follow this approach then this will look like separate cache >>> component but it will reside within server itself. >>> >>> However we need to discuss this further and come to conclusion. >>> >>> Thanks, >>> sanjeewa. >>> >>> On Tue, Aug 9, 2016 at 11:13 AM, Sineth Jayasinghe <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> The WSO2 API manager has a well defined REST API conforming to >>>> Richardson Maturity Level 2. In order to make it conforming to Level 3, we >>>> need to have cache and concurrency controlling capabilities. This could be >>>> achieved by supporting the appropriate http cache and concurrency >>>> controlling headers such as E-Tag, However the exact design and >>>> implementation of this still remains a question. >>>> >>>> - The E-tag for a particular resource will have to be generated >>>> based upon, >>>> >>>> >>>> 1. All updatable fields in a resource >>>> 2. Policies imposed upon the resource/endpoint >>>> 3. Time-stamp of the last update for a resource >>>> >>>> we can either use *one or several of them combined* to make the E-Tag >>>> and make use of a hashing algorithm like MD5 or SHA-128 to make a the hash >>>> value for the E-Tag. >>>> >>>> if you have any insight/ opinion/ improvement on this design approach >>>> please be kind enough to reply to this mail and thanks in advance.. >>>> >>>> -- >>>> Sineth Neranjana, >>>> Intern, >>>> WSO2 Inc. >>>> Mobile +94-716033698 >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sineth Neranjana >> Intern >> WSO2 Inc. >> Mobile +94-716033698 >> >> >> _______________________________________________ >> 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 > -- 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
