3 ms·

> Stateless does not mean that servers and clients do not have state, it simply means that they do not need to keep track of each other’s state. For this reaso

> Stateless does not mean that servers and clients do not have state, it simply means that they do not need to keep track of each other’s state. For this reason, I've always thought that the term "stateless" is confusing. Maybe "client state independent" (the response that the server sends back is independent of the client's state)? I don't love that term, any better ideas?

andreyf 11y ago
Client-agnostic? That seems to imply no id's on the clients at all, though.
markbnj 11y ago
I don't think it's confusing because it says exactly what it is supposed to say. 'Stateless' is not a property of the client, or the server, but of the relationship between them, and that relationship is expressed in the protocol they use to communicate.
- tie_ 11y ago
  The relationship between client and server is not stateless in the majority of the cases. Most of the implementations rely on authentication state (cookie, session secret). Very few actually do the stateless part right.
  - kuschku 11y ago
    If your authentication token times out, it’s not ReST. As simple as that.
    - emmelaich 11y ago
      Is that true? The token may have the time encoded in it. When the token is presented to the server it responds with a 401. The client can then use the WWW-Authenticate response to know what to do next. None of this requires state on the server.
      - kuschku 11y ago
        But it requires a state on the client still. I need to store a state somewhere at least. That’s not really stateless.
    - e12e 11y ago
      If you're using an authentication token, it's not really REST. Because of the dire situation wrt. client certificates, the only straight-forward, "pure" REST, would be to supply Basic Auth on every request (that doesn't allow anonymous access). I'm not really convinced that's not a good idea for a TLS-only service (compared to the complexities that tokens/cookies introduce). One reason why there was a move away from Basic Auth was ofcourse that it is crazy to send plain-text login/password pairs over a plain-text transport (HTTP sans S). And there's never been any working, cross-platform effort to improve things (AFAIK). There's some work on Kerberos that's interesting, but again, many of these efforts have been simply co-opted by the fact that everyone used cookies (and had problems, and started encrypting them etc), and then moved from HTTP to HTTPS. When you have HTTPS, there's not that many reasons to not just have "SECRET PASSWORD" in the URL (granted that'd not be REST either, but BASIC AUTH does the same thing, just in a header).
      - kuschku 11y ago
        Indeed, this is the point I wanted to get to. If you have to do a challenge-response auth every 5 requests, or so, to get a session, then it’s not really rest. Client certificates might actually make the most sense in this case.
    - andreineculau 11y ago
      Please reconsider this non-sense. Timeouts have nothing to do with being stateless. A good read: https://www.safaribooksonline.com/library/view/restful-web-services/9780596529260/ch08s16.html https://www.safaribooksonline.com/library/view/restful-web-s...
  - markbnj 11y ago
    Agreed, it's very difficult to get to a completely stateless protocol and still support stateful ideas like authentication.
  - e12e 11y ago
    It's probably the biggest problem with pairing HTTP(S)/1.1 and REST. TLS/SSL will require a session that is much more "bound" (entangled?) -- and really would be the sane place to keep track of authentication/id bindings (Who is the client?) -- and use as a basis for authorization (What does this client have access to). But because of the "bolt-on" nature of TLS, we get things like TLS terminating proxies/load-balancers etc, and a lot of passing flags in headers (ProyxN confirms that it's relaying over plain-text HTTP on the (assumed to be) secure internal network, on behalf of clientX that's connected over TLS and has been authenticated...). The "simple" answer is to have client-certificates, and allow a client access directly to an application server over TLS, or use a secure transport (eg: IPSec), and just use standard HTTP auth on every pass (which AFAIK never was extended to use some form of standardized token, so one's left with sending the actual login/password pair every time). The sane compromise is to just use encrypted cookies -- but they are also bolt on solutions. The problem is that essentially one needs encryption to ensure secure sessions, which essentially boil down to authenticating the client to the server, and the server to the client, and forming some kind of session (typically DH for a symmetric session key). For a long while, encryption was really expensive compared to the db lookup and template render that "every" web application did -- and so we've ended up with a mess of "best practices" which aren't very good at all (and not a very good way of moving from REST-that-trusts-plaintext-ip to REST-and-also-secure). With HTTP/2 it looks like things are moving towards making the transport-protocol part do the things it should -- track the session, and secure the session. Still doesn't do a good job of authenticating the client in any meaningful way, but it should simplify some of the assumptions that are necessary to build a secure(ish) system.

andreyf 11y ago

Client-agnostic? That seems to imply no id's on the clients at all, though.

markbnj 11y ago

I don't think it's confusing because it says exactly what it is supposed to say. 'Stateless' is not a property of the client, or the server, but of the relationship between them, and that relationship is expressed in the protocol they use to communicate.

tie_ 11y ago
The relationship between client and server is not stateless in the majority of the cases. Most of the implementations rely on authentication state (cookie, session secret). Very few actually do the stateless part right.
- kuschku 11y ago
  If your authentication token times out, it’s not ReST. As simple as that.
  - emmelaich 11y ago
    Is that true? The token may have the time encoded in it. When the token is presented to the server it responds with a 401. The client can then use the WWW-Authenticate response to know what to do next. None of this requires state on the server.
    - kuschku 11y ago
      But it requires a state on the client still. I need to store a state somewhere at least. That’s not really stateless.
  - e12e 11y ago
    If you're using an authentication token, it's not really REST. Because of the dire situation wrt. client certificates, the only straight-forward, "pure" REST, would be to supply Basic Auth on every request (that doesn't allow anonymous access). I'm not really convinced that's not a good idea for a TLS-only service (compared to the complexities that tokens/cookies introduce). One reason why there was a move away from Basic Auth was ofcourse that it is crazy to send plain-text login/password pairs over a plain-text transport (HTTP sans S). And there's never been any working, cross-platform effort to improve things (AFAIK). There's some work on Kerberos that's interesting, but again, many of these efforts have been simply co-opted by the fact that everyone used cookies (and had problems, and started encrypting them etc), and then moved from HTTP to HTTPS. When you have HTTPS, there's not that many reasons to not just have "SECRET PASSWORD" in the URL (granted that'd not be REST either, but BASIC AUTH does the same thing, just in a header).
    - kuschku 11y ago
      Indeed, this is the point I wanted to get to. If you have to do a challenge-response auth every 5 requests, or so, to get a session, then it’s not really rest. Client certificates might actually make the most sense in this case.
  - andreineculau 11y ago
    Please reconsider this non-sense. Timeouts have nothing to do with being stateless. A good read: https://www.safaribooksonline.com/library/view/restful-web-services/9780596529260/ch08s16.html https://www.safaribooksonline.com/library/view/restful-web-s...
- markbnj 11y ago
  Agreed, it's very difficult to get to a completely stateless protocol and still support stateful ideas like authentication.
- e12e 11y ago
  It's probably the biggest problem with pairing HTTP(S)/1.1 and REST. TLS/SSL will require a session that is much more "bound" (entangled?) -- and really would be the sane place to keep track of authentication/id bindings (Who is the client?) -- and use as a basis for authorization (What does this client have access to). But because of the "bolt-on" nature of TLS, we get things like TLS terminating proxies/load-balancers etc, and a lot of passing flags in headers (ProyxN confirms that it's relaying over plain-text HTTP on the (assumed to be) secure internal network, on behalf of clientX that's connected over TLS and has been authenticated...). The "simple" answer is to have client-certificates, and allow a client access directly to an application server over TLS, or use a secure transport (eg: IPSec), and just use standard HTTP auth on every pass (which AFAIK never was extended to use some form of standardized token, so one's left with sending the actual login/password pair every time). The sane compromise is to just use encrypted cookies -- but they are also bolt on solutions. The problem is that essentially one needs encryption to ensure secure sessions, which essentially boil down to authenticating the client to the server, and the server to the client, and forming some kind of session (typically DH for a symmetric session key). For a long while, encryption was really expensive compared to the db lookup and template render that "every" web application did -- and so we've ended up with a mess of "best practices" which aren't very good at all (and not a very good way of moving from REST-that-trusts-plaintext-ip to REST-and-also-secure). With HTTP/2 it looks like things are moving towards making the transport-protocol part do the things it should -- track the session, and secure the session. Still doesn't do a good job of authenticating the client in any meaningful way, but it should simplify some of the assumptions that are necessary to build a secure(ish) system.