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
