It's confusing to me to interpret the term "stateless" in REST API. For example, when reading this article it has the following text:

The last principle I want to address is stateless communication. First of all, it’s important to stress that although REST includes the idea of statelessness, this does not mean that an application that exposes its functionally cannot have state — in fact, this would render the whole approach pretty useless in most scenarios. REST mandates that state be either turned into resource state, or kept on the client. In other words, a server should not have to retain some sort of communication state for any of the clients it communicates with beyond a single request.

For this, I understand that the API application mentioned in the title of this question is stateless because the session is used for user authentication (it stores the user's state not the application state).

Is my understanding correct?

If not how about the application using JWT tokens for authentication but also store JWT in a database (either on the same server or on a different server), is it still considered stateless?

It's confusing to me to interpret the term "stateless" in REST API. For example, when reading this article it has the following text:

The last principle I want to address is stateless communication. First of all, it’s important to stress that although REST includes the idea of statelessness, this does not mean that an application that exposes its functionally cannot have state — in fact, this would render the whole approach pretty useless in most scenarios. REST mandates that state be either turned into resource state, or kept on the client. In other words, a server should not have to retain some sort of communication state for any of the clients it communicates with beyond a single request.

For this, I understand that the API application mentioned in the title of this question is stateless because the session is used for user authentication (it stores the user's state not the application state).

Is my understanding correct?

If not how about the application using JWT tokens for authentication but also store JWT in a database (either on the same server or on a different server), is it still considered stateless?

• rest

Share Improve this question Follow edited 19 hours ago VLAZ 29.1k99 gold badges6363 silver badges8484 bronze badges asked 21 hours ago Kt StudentKt Student 16811 silver badge55 bronze badges 2

• 1 You could of course argue that a session is a resource, which you create by logging and and delete by logging out. And as long as it is used only to cache the user auth info, not to store some "user's state" (what do you mean concretely?), it is even less stateful. – Bergi Commented 21 hours ago
• Stackoverflow's headline is "Get answers to practical, detailed questions" but this sounds more like a discussion of semantics than anything practical. Whether or not it is considered stateless is probably less important than if it causes a practical problem for you. – Quentin Commented 19 hours ago

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

The authoritative definition of REST is Fielding's 2000 dissertation. Fielding's explanation of the stateless architectural constraint is in chapter 5.

each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.

Contrast this with something like FTP, where commands are interpreted within the context of the session on the server (which "remembers" PWD, and modes, and user, and so on).

It might also be worth reviewing chapter six, where Fielding discusses mismatches between REST and HTTP, including: cookies.