Hi All, we had a discussion on this E-tag generation problem and decided to move ahead with last updated time-stamp of the resource to be used for E-Tag generation. In *actual generation of the E-Tag we can use MD-5 hashing* or even SHA-256 to hash the time-stamp and I believe this will not cause that much of a performance degradation.Furthermore, some of the database tables will be getting some new fields such as
1. CREATED_TIME 2. UPDATED_TIME 3. CREATED_BY 4. UPDATED_BY Is there some more things to be added into this E-Tag generation scenario ??. Regards, Sineth. On Thu, Aug 11, 2016 at 9:16 AM, Sineth Jayasinghe <[email protected]> wrote: > Hi frank, > Thanks for the tip on 'if-unmodified-since' header and data corruption is > the last thing we wanna have. so i think a E-Tag implementation based on > either the last updated time stamp for the resource within the cache or the > time stamp within the database would serve good enough for our task. > > On Wed, Aug 10, 2016 at 8:22 PM, Frank Leymann <[email protected]> wrote: > >> Hi all, >> >> there is an important subtlety between using ETag and Last-Modified >> headers for concurrency control: Last-Modified is of type "HTTP-date", the >> precision of which is "second". Thus, multiple update happening within >> one-and-the-same second will not be distinguished by using the >> "If-Unmodified-Since" >> header in conditional requests: in highly concurrent environments, this >> won't allow correct concurrency control. As a consequence, we have to use >> an ETag for concurrency control in case we expect "frequent" updates of the >> resources of a product/feature. >> >> >> Best regards, >> Frank >> >> 2016-08-10 4:44 GMT+02:00 Joseph Fonseka <[email protected]>: >> >>> Hi All >>> >>> IMO the key benefit of implementing ETag would be to support caching and >>> to reduce the server load. Concurrency control would be a added benefit >>> otherwise which can be implemented by having "Last-Modified" and >>> "If-Umodified-Since" in a simpler way. >>> >>> Given above. >>> 1. If we hash the full payload that would only save bandwidth and in >>> fact it will increase the server load since we have to hash large payloads. >>> If we hash just one attribute like last-updated field that would reduce the >>> hashing overhead to generate ETag. >>> >>> 2. As @Malintha mentioned if the REST APIs is the only entry point to >>> the data we can manage an ETag cache at the REST API layer and invalidate >>> it if a PUT is performed. I am not sure that would be a good solution for >>> us since we want to allow our java API to be used by other components. >>> >>> 3. Above lead us to think the cache should be maintain at the java API >>> (impl) layer to track updates which can be read by REST APIs to generate >>> ETags and serve conditional statements. >>> >>> Regards >>> Jo >>> >>> >>> On Tue, Aug 9, 2016 at 5:35 PM, Frank Leymann <[email protected]> wrote: >>> >>>> Sanjeewa, >>>> >>>> yes, Level 3 of the Richardson Maturity Model is about HATEOAS. And we >>>> agreed to not support HATEOAS because there are no accepted best practices >>>> around that, especially, how clients would make effective use of it. >>>> >>>> Level 2 is about proper use of HTTP methods, which *includes* use of >>>> applicable status codes returned, and making use of the various header >>>> fields applicable to the methods - which is what *proper use of HTTP >>>> methods *is all about. And the REST Guidelines document specifies same >>>> techniques that are centered around these headers, namely caching, >>>> concurrency control, long running requests etc (and there are more >>>> techniques). Thus, caching, concurrency control etc is an aspect of Level >>>> 2. And we strive towards Level 2 support. >>>> >>>> But this does not imply that each of our products are required to >>>> support caching, long running request etc.. Which of these advanced >>>> techniques is to be supported has to be centered around requirements - and >>>> each product team likely understands those best. For example, if all >>>> requests can be responded "synchronously", there is no need to support long >>>> running requests; if a single administrator is manipulating resources at a >>>> time, you don't need to support concurrency control etc. >>>> >>>> I am happy to discuss details about these advanced techniques. Also, if >>>> you wan to discuss requirements and how they might map to REST, let's >>>> discuss it. This will all contribute a version 2 of our REST API >>>> Guidelines. >>>> >>>> >>>> Best regards, >>>> Frank >>>> >>>> 2016-08-09 11:42 GMT+05:30 Sanjeewa Malalgoda <[email protected]>: >>>> >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> >>> -- >>> *Joseph Fonseka* >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 772 512 430 >>> skype: jpfonseka >>> >>> * <http://lk.linkedin.com/in/rumeshbandara>* >>> >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Sineth Neranjana > Intern > WSO2 Inc. > Mobile +94-716033698 > > -- Sineth Neranjana Intern WSO2 Inc. Mobile +94-716033698
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
