What was the outcome of this implementation? Have we added this feature to product? Is this documented?
Thanks, sanjeewa. On Thu, Aug 18, 2016 at 12:15 PM, Sineth Jayasinghe <[email protected]> wrote: > 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 <071%20603%203698> > > -- *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
