Re: the meaning of stateless

On Tue, Apr 23, 2013 at 9:14 AM, Brian Craft <[email protected]> wrote:

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

Let's take this as a specific example:

POST /createquery

<lots of query information>

returns
301
Location: /queryresult/1234

POSTing to create query creates a query result, and then redirects you to
that identifier. The query result is a resource, you can GET that result
all day long. Is that result dynamic? Is it a cached result set? That's up
to the service to decide. The system may well delete all query results
after 1hr. That's valid too.

It can also tie that result specifically to you, in that it only lets you,
who authorized as Brian, access query result 1234.

But you can see, that POST /createquery has clearly defined semantics -- it
creates a query result. Then, GET /queryresult/<resultid> returns that
information that was previously created.

Now, consider:

GET /latestqueryresult

Which returns "the most recent query result for the user".

Does this violate "cannot take advantage of any stored context on the
server"?

We can easily see the /createquery process creating not just a
/queryresult, but a /latestquery/brian result. There's no limitation about
a process creating affecting a single resource.

All of the information required to achieve the result is in the request:
the URL itself (/latestqueryresult) as well as the identification of the
user (Authorization: ...). It's also pretty well accepted that the
Authorization header can affect the outcome of a request. And if there's
anything that an Authorization header represents, it's store context on the
server.

Well, now, how does an Authorization header get any more credence to affect
an operation than a Cookie header?

So, what we're now stumbling in to is the definition of "Request". What
does a request consist of? Just the URL? URL and Authorization Header? What
about the Accept headers? They must count for something. So how is a cookie
any different? Or any other additional header?

The issue isn't so much the request itself, it's not an issue with cookies
per se. It's an issue of misuse on the server. Specifically Sessions.

It's a problem with hidden conversational state, however manifested (you
can represent a Session ID with a query fragment, for example). It goes
toward the goal of coarse, self contained transactions being a fundamental
core principal of the REST architecture. It's a "spirit of the rule" vs the
"letter of the law". As a general rule, you should be able to take requests
wholesale, hand them to any server in the system and get the proper result.
Making the requests work on first class resources, rather than
conversational state discreetly maintained, empowers things like proxies,
caching, serendipitous reuse.

For example, when you POST to /createquery, perhaps instead of creating a
new queryresult, the system realized it already had one that was "current
enough" and simply returns the URL to that one. You can easily see
something like Google doing that. Internally caching popular queries for a
minute.

But any item typically considered as conversational state can be uplifted
to a first class resource (the Transaction pattern being a germane
example). The loss of implicit stored server context makes you rethink the
problem and bring all of these attributes in to the open, where they can be
analyzed more readily, and perhaps repurposed later. Having first class
resources means that everything shares the same fundamental properties.
Improve the capabilities of these of that foundation, and you potentially
uplift the entire infrastructure.

-- 
CONFIDENTIALITY NOTICE: The information contained in this electronic 
transmission may be confidential. If you are not an intended recipient, be 
aware that any disclosure, copying, distribution or use of the information 
contained in this transmission is prohibited and may be unlawful. If you 
have received this transmission in error, please notify us by email reply 
and then erase it from your computer system.