Re: the meaning of stateless

Stateless refers to shared state, meaning state that is "carried over"
implicitly between requests.

If the client posts a query, and the server responds with a link to a URL
identifying the specific result of that query as a resource that's normal
server persisted state..

But if the client posts to a /query endpoint and then makes a get to a
generic /result endpoint then the state (or context) is implicitly carried
over and therefore there is no visibility in the second request. I.e there
is shared state and the constraint is violated.

Cheers,
M
On 23 Apr 2013 17:14, "Brian Craft" <[email protected]> wrote:

> **
>
>
>
>
>
> On Mon, Apr 22, 2013 at 4:18 PM, Mark Baker <[email protected]> wrote:
>
>> On Sun, Apr 21, 2013 at 7:52 PM, Brian Craft <[email protected]>
>> wrote:
>> > Fielding's definition didn't do much for me, because the terms aren't
>> adequately defined,
>>
>> They are, and the definition is most definitely adequate, trust me on
>> that.
>
>
> I don't agree. Take this statement, for example:
>
> "Each request from client to server must contain all of the information
> necessary to understand the request, and cannot take advantage of any
> stored context on the server. "
>
> What does "understand" mean in this sentence? I'm not aware of a technical
> definition of "understand" as it applies to computer systems, and it's not
> defined in the paper. Again, take the "query by POST" pattern. The eventual
> GET depends on a previous POST. Does the server "understand" a request that
> depends on a previous request? What about "stored context"? One would
> reasonably believe that POSTing a query creates stored context on the
> server which later requests may take advantage of. But this sentence says
> that it must not "take advantage of any stored context on the server." I
> assume this apparent contradiction is due to some different use of terms,
> that "stored context" doesn't mean what one would reasonably assume it
> means, or something. If this is a different usage of the terms, they should
> be defined somewhere.
>
> My current guess is that "understand" means that the communications layer
> can read the request and generate a valid response, including the case
> where the POST goes missing and it must return a 404: that it still
> "understands" the request even though the app can't process it since the
> depends on a previous request.
>
> But then it gets really odd with claims like "the server doesn’t have to
> manage resource usage across requests." How is a POSTed query not a
> resource on the server that must be managed across requests? Again, if this
> is to make sense then the terms must have something other than their usual
> meaning. Is it "manage"? Maybe the server doesn't "manage" the resource
> because the client directs the creation of it? But, then, the server will
> have to manage the destruction of it, because a server can't allow clients
> to create an unbounded number of transient "query" objects and count on the
> clients to clean up after themselves. So what does that phrase mean?
>   
>