W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2002

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

From: Jeff Lansing <jeff@polexis.com>
Date: Mon, 06 May 2002 14:58:37 -0700
Message-ID: <3CD6FC8D.616D6B56@polexis.com>
CC: www-ws-arch@w3.org
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
Received on Monday, 6 May 2002 17:58:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:59 GMT