Can anyone give me an example of truly stateless RESTful endpoints? a simple question, if server is completely stateless, how do we invalidate previous tokens? I consider saving state to DB as bad practice. lets say there are hundreds of requests per second, that would mean hundreds of queries to DB per second (if you save state to DB) and that's bad news. if you save state to server, you'll run into session transfer problem when using multiple servers and load balancers.
Asked
Active
Viewed 575 times
0
-
1I don't see what the problem is with the database access, that is something you simply scale horizontally if you run into performance issues. – Gimby Jan 22 '16 at 08:04
-
you seem to have contradicting parts of question in this one - I answered the first one. It's certainly possible, but not with the additional requirements you pose. – eis Jan 22 '16 at 08:21
2 Answers
0
Well one example of course would be endpoints that don't need authenticating, and dependent on your structure there are others. For example if you are using something like AngularJS you don't need to have authorization in the same way as you would use it with something like a developer API - you can use session variables which can be signed and stateless.
If you are worried about performance of performing database queries on simple state things like this, it is worth looking at some solutions like Redis, which you can send hundreds of queries to with very little strain.
Will
- 810
- 6
- 21
-
signed session variables? but server will need to check that, right? and in order to check that, it has to check against "something". stateful again. am I missing anything? – Thomas Jan 22 '16 at 07:41
-
The session variables can be signed using a key that is shared between your systems as a config option. Let's say you have a secret that is: "nhvOcg4hLgc1ieN" You would make it so each of your servers knows what that is and then it cryptographically signs each session with that key. They just need to verify the signature rather than check a database. – Will Jan 22 '16 at 08:14
0
Stateless restful endpoints by definition wouldn't use tokens (having a lifetime) or state. If you need those, then you don't have a truly stateless restful endpoint.
As an answer to your question, a web server without authentication or a similar mechanism could be considered truly stateless rest endpoint. It would just deliver a file from disk on GET request to anyone requesting it.
Also, if authentication is hardcoded basic auth or similar mechanism sending login details on every request, it would be still stateless. When you start adding tokens that expire you definitely already have state.
For details on doing authentication in a stateless REST manner you can read up on this discussion.
-
I cannot agree. See [this article](http://www.kaleidos.net/blog/295/stateless-authentication-with-api-rest/) for example. Or have you ever seen [User Access Tokens](https://developers.facebook.com/docs/facebook-login/access-tokens) which e.g Facebook uses? REST is about transferring state between client <-> server, and thus keeping server **Stateless**. – G. Demecki Jan 22 '16 at 14:14
-
That article talks about storing the state fully on client, making the rest service stateless. What I said that stateless restful endpoints by definition wouldn't *use* tokens or state, which is what article also confirms - rest endpoint is not using tokens/state there, it's only used on the client side. – eis Jan 22 '16 at 15:39
-
No offence, but weird words: `Stateless restful endpoints (..) wouldn't use tokens` - when client passes a token to the server, the server clearly *make use* of that token (without storing it) for authentication. – G. Demecki Jan 22 '16 at 16:56
-
@G.Demecki I understood the article so that client never passes the tokens to server, but instead uses them only on client side. – eis Jan 24 '16 at 15:11