Stateless vs. Stateful

[Kegan Abbott]

Hi Guys:

I'm new here, but loving the community so far. 

One of the things I'm struggling with getting a clear answer on, is Stateless vs. Stateful APIs. I understand that Stateful is necessary for mobile applications etc. but am I missing something? Is one better than the other?

Thanks for the help! 

[Mike Kelly]

stateless, from an web architecture point of view, refers to shared
state between client and server.

In short, if the intent of a given request can't be understood purely
from the message itself and instead requires the implicit context of
some previous client server interaction - then that's not stateless.

e.g: a request to GET /about/me that depends on a cookie previous set
via a POST request to /auth is not stateless

Cheers,
M

> --
> You received this message because you are subscribed to the Google Groups
> "API Craft" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to api-craft+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123

[Kegan Abbott]

Awesome. Thanks for the help!

[Fernando Cordeiro]

e.g: a request to GET /about/me that depends on a cookie previous set
via a POST request to /auth is not stateless

What if it's

GET /about/me/:access_token
Where the access Token was formerly provided by the Auth?

Or simply, what are the best practices in regards to Auth? What's the 'proper' way to do it?

[Jørn Wildt]

That's almost fine :-) But access tokens belong to the HTTP Authorization header not in the URL.

An access token that requires a database lookup is not much different from a session cookie and is, at it's core, not stateless since the message itself cannot be understood completely without more information.

An access token that contains enough user information to avoid looking up more information on the server makes the whole system stateless (unless, of course there is other context dependent stuff).

Try googling "HTTP Authorization header" or "OAuth2 bearer token" or "JWT JSON Web Token" (or try http://en.wikipedia.org/wiki/Basic_access_authentication for a starter).

I recently gave this answer about web authorization which might be useful too: http://stackoverflow.com/questions/21506843/rest-api-authentication-for-web-app-and-mobile-app/21600804#21600804

/Jørn

--

[Adam Davies]

I'm hearing what people are saying regarding statelessness, but when all is said and done the server needs some state. Whether this is in the header, or part of a URL, or in the payload does not really matter. What matters is that the server may need to know something about who is making the request.

IMHO the concept of statelessness is not about having no state, it's more of a desire that the server can respond to a request without having to check that some call was made previously. Rob Fielding described this a Client-Stateless-Server (CSS). However, this is OK for serving stateless resources such as files or simple GETs, but is not practical for eCommerce or financial applications (for example). The reason is that the CSS model implies that each request must 'contain all the information necessary to understand the request', which means that if you want the server to process your shopping cart then you must pass all that shopping cart, delivery address, payment details etc in  with the request. Of cause that isn't practical. You need as a minimum some validation, but as a practial concideration you probably want to store most of that stuff on the server and just have a simple /cart/99999/checkout type request, so on the server side you have to know whose making the call. It also means that the user must have entered payment and delivery address before making that call.

Statelessness in IMHO is more about the client transferring state via a request which causes the server to transition to and returning a new state.

In general, all resources are in some form of state, even if it is an initial state (i.e. empy basket), and may be transitioned to another state via a request (add item to basket). The client is responsible for understanding the 'application' state and requesting transitions, the server is responsible for the actioning transitions and creating new states.

The desired model of 'statelessness' is the process that when server gets your request, it will wake-up gather the required data, update what needs updating, respond, go back to sleep. A kind of Event process model. No state processing need to be done or maintained between request. This is what gives you the visibility, reliability, and scalability that Rob talks of.

[Mike Kelly]

On Thu, Feb 6, 2014 at 9:34 PM, Adam Davies <cleved...@googlemail.com> wrote:
> I'm hearing what people are saying regarding statelessness, but when all is
> said and done the server needs some state. Whether this is in the header, or
> part of a URL, or in the payload does not really matter. What matters is
> that the server may need to know something about who is making the request.

That is not true. There are *many* resources on the web (images,
video, css, javascript) that can, and are, served efficiently by web
infrastructure leveraging the stateless nature of HTTP.

Cheers,
M

[Felipe Sere]

I wouldn’t consider a DB such a big deal when looking at ‘stateless’ vs ’stateful’.

The whole point of statelessness is to scale big. Add servers without caring. If you use magic such as sticky-sessions (for session stuff),

you are not really able to distribute the load evenly across n servers, as the server that is going to be used depends on the initial request.

AccessTokens and whatever is sent across the wire the request (even if it results in a DB lookup) is per-se stateless, as any server in the cluster can perform the same db query and answer just as any other….

[Kijana Woodard]

And the db is happenstance. You could have the information available in memory for lookup.

[Felipe Sere]

“In memory” is an issue if it is local to the servers.

As long as any server in the cluster can answer the request you are pretty much fine :)

[Kijana Woodard]

The data _could_ be available in memory on all servers. We use a db because it's convenient and there is lots of tooling to support it.

I don't think stateless has to mean "the server can't lookup information".

[Felipe Sere]

That was exactly my point :)

Lookup is fine as long as any server in a cluster gets the same answer. Server-local caches break that… 

[Kijana Woodard]

We agree in principal.

I merely extended your point. Imagine some long lived reference data which could even be username/pwd or permissions. Those could be cached on every server in memory and kept in sync via { insert magic of choice here }.

Given the above, would looking up info in memory violate statelessness? If not, how does looking it up in a remote db violate statelessness? If so, there are very few stateless _apps_ in existence.

I assume something like claims sent with a token is considered more stateless than looking up authorization in a db.

I've always taken the stateless dictate to mean something like:

Given POST /foo followed by POST /bar, there is no server state that "knows" POST /foo occurred "recently".

That is subtly distinct from POST /foo altering application state such that POST /bar is possible. So POST /bar doesn't try to check if you have done POST /foo, it checks whether POST /bar is possible given the application's current state.

[Mike Kelly]

Also, auth can be implemented as an HTTP layer sitting in front of the
origin server. Taking this approach then frees up you origin servers
(or any other layer behind the auth layer e.g. caching) to again deal
with the requests in a stateless fashion.

Cheers,
M

[Pedro Santos]

Let me reinforce Jørn advice: Never EVER put sensitive info on query parameters or URIs!

As for the statefull/stateless question while you can go the crypto route as Jørn sugested, you still need to check for revocation*, and that is only possible by storing "state" (either of valid tokens or revoked ones). I say "state" and not state (no quotes) because in this specific case I don't think it violates the stateful constraint... Doesn't a server need to have access to "state" of a representation for example to determine if a condicional PUT can be done? Having OAuth tokens stored in-memory or in a DB is the same thing imo. You could actually say that the client first creates an access token representation (POST /token) and later includes that representation (or a part of it to be more accurate) in every request.


* You can of course not have a revocation validation (the short lifespan the less appealing it is to have revocation mechanisms) but if you do, then you have to have "state".


Cheers,
Pedro

[Fernando Cordeiro]

Sorry, I'm still learning API Developmet, but why exactly shouldn't I send sensitive in fo on URIs ou Query Parameters?

And this doesn't include Post Parameters, right...?

[erewhon]

The URL is frequently logged and highly visible.  Applications that understand HTTP can deliberately apply protections around the Authorization header (or other properties of your request that HTTP identifies as security related).  Think caching layers (e.g. varnish), web server logging, etc.  It's harder to protect that information when it's in a URL, which is largely an arbitrary string.

[Pedro Nuno Santos]

Usually POST parameters go in the body, so that's ok. The reason you shouldn't include sensitive information in URIs or query parameters is that, like erehorn said, ever proxy, gateway or intermediary betwen the client and the intended server will have access to the URI and query parameters (even in an HTTPS connection).

Unless you are somehow encrypting query parameters (or URI segments that contain sensitive information) they are there for "everyone" to see. That's why it's strongly discouraged to include sensitive information in URIs or query parameters.

--
You received this message because you are subscribed to a topic in the Google Groups "API Craft" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/api-craft/go32mXbnPk8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to api-craft+...@googlegroups.com.

[Pedro Nuno Santos]

*erewhon (sorry bout that eheh)