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

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.

Please reconsider this non-sense. Timeouts have nothing to do with being stateless.

A good read: https://www.safaribooksonline.com/library/view/restful-web-s...