Hi, On Mon, Dec 5, 2011 at 4:45 PM, Marcel Offermans <[email protected]> wrote: > On Dec 5, 2011, at 14:55 PM, Bram de Kruijff wrote: >> 2011/11/30 Ivo Ladage-van Doorn <[email protected]>: >>> >> I think we are not doing REST >> style interfaces just because they look nice or network effects, but >> ultimately to achieve a highly scalable and reliable architecture >> through stateless design. You can't do that by being a little RESTish >> and relying on session state and as this is part of how we design >> stuff I personally would not like to see any "yea buts" here. I do >> agree with Paul that we may want to make "context" a little more >> explicit in some way. > > I agree, so are you saying that we should never ever depend on anything in > the HttpSession, not even things like authenticated users? I'm actually +0/+1 > on that. ;)
Well yes and no... I can think of implementations that use this mechanism eg for optimization/caching, but it must not be designed on it. So this means a couple of things.. 1) No matter if you keep state in the session, the interface cannot have a statefull behavior. I think we all agree on this...? Consequently, when talking about authentication, credentials in some form must at each call be past in for the authentication layer. 2) Maybe you keep the cacheable result of an expensive authentication check on a remote identity server in a local cache/session.. fine, but when that cache is empty (eg. because the sessionid was not passed in after a fail over) all should still work as expected. So, authentication/authorization sessions should preferably work based on a reference-able token (session as a resource) which I think is the basic idea behind the identity/session management as described at [0]. If that service in any particular application domain allows me to cache (HTTP caching) session state and or identity data and or auth credentials you are free to use whatever mechanism locally to optimize that as long as you do not break the contract. My personal preference on HttpSession sepcifically is that as the caching is on http level you can probably use a simple singleton cache as easy as HttpSession. So why introduce the smell and lockin to javax anyway? But I guess this more a discussion for the web framework authentication mechanism. grz Bram [0] http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Identity+Server > I am definitely +1 on your argumentation on why we're doing REST btw. > >>> [Marcel] I don't want to require 2 types of content negotiation, when the >>> whole concept of content negotiation is optional in the HTTP spec: >>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html >> >> Not sure what you mean by "the whole concept" being optional.. But at >> least the spec says a server SHOULD honor Accept. > > What I mean is that providing these Accept headers is optional. I agree that > if they are provided, they should be honored. I guess I don't see the point > of re-iterating what's already in the spec (nor providing additional rules on > top of it). > > Greetings, Marcel > > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
