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

Similarly, any service that acts as a database is questionable, and a service that acts as a
database that lets users define new tables is totally out.

Jeff

"Narahari, Sateesh" wrote:

> >>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