On Dec 5, 2011, at 14:55 PM, Bram de Kruijff wrote: > 2011/11/30 Ivo Ladage-van Doorn <[email protected]>: >> 1.2 >> >> [Paul] Stateless - "context" might be unclear. You are allowed to keep >> application state (such as the workspace mechanism in ACE), you should only >> never rely on (HTTP) session state. >> >> There is a lot to say about this topic, but the requirement “we never rely >> on the HTTP session state” is not that easy to fulfill. Right now we do >> depend on the HTTP session; to remember authenticated users. Without that we >> would need to post username/password with each request, which would >> introduce a security issue. Using sticky sessions or session replication >> would also violate the being stateless requirement. See also >> >> http://blog.dhananjaynene.com/2009/04/what-is-statelessness-in-rest/ >> >> So do we really want to stick to this strict definition of being stateless? > > Yes we do want to be strict. It may be true that there are some grey > areas when defining application state versus conversational state, but > the bottom line is that it MUST be one or the other and when it is > conversational it MUST be on the client.
Agreed. As a background note, the workspace mechanism in ACE is application state and it's actually logically kept on the client. It's just that we happen to deploy those client bundles on the server. Scalability here can be achieved (even though I don't think it will ever become an issue) by moving those client bundles onto a different compute node, and in fact, you can easily put it on as many nodes as you want and load balance it (provided you keep each client on the same machine for the duration of manipulating that workspace). > 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. ;) 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
