RE: should web services be strictly stateless accessible thru bro wser and RDFying HTML etc...

>>In Web architecture, "stateless" refers to the notion that all the
>>information necessary to process a message is available in the message
>>itself.  This provides lots of benefits, primarily improved visibility
>>(intermediaries can understand what's going on as well as the end
>>points), and scalability (the server isn't required to remember anything
>>about the client, and consume resources doing it).

>>Note that cookies are stateful.

So, a web service named setQuoteList, followed by retrieveQuoteUpdate is not
possible as per new architecture, if the web service remembers the list of
ticker symbol between these two calls.

Similarly, security web services may not be possible, because, if a security
token is created and given to the client, the security service ( web
service) is remembering the information on the token ( for revalidation
etc), unless ofcourse every revalidation is a new authentication. Obviously
intermediaries may not understand what's going on. 

I think there are a good deal of applications where there is a need to
remember something about the client be it a user table, or user preferences.


IMO, statelessness is a limiting requirement as per this interpretation of
statelessness, and does not work for well for web services.


-Sateesh

Received on Monday, 6 May 2002 17:44:54 UTC