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
