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
