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
