In a stateless API, the server does not keep request-to-request “session” state; each request carries everything needed (e.g. token, IDs). In a stateful API, the server stores session state (e.g. in memory or DB) and often relies on a session identifier (cookie) to find it.
Stateless: every request self-contained
sequenceDiagram
participant C as Client
participant S1 as Server 1
participant S2 as Server 2
C->>S1: Request + token/session ID
S1->>S1: Validate token (no local state)
S1-->>C: Response
C->>S2: Same token (e.g. load balancer)
S2->>S2: Validate token (no local state)
S2-->>C: Response
Note over S1,S2: Any server can serve any request
Stateful: server stores session
sequenceDiagram
participant C as Client
participant S1 as Server 1
participant S2 as Server 2
participant Store as Session Store
C->>S1: Request + session cookie
S1->>Store: Get session(sessionId)
Store-->>S1: Session data
S1-->>C: Response
C->>S2: Same cookie (different server)
S2->>Store: Get session(sessionId)
Store-->>S2: Session data
S2-->>C: Response
Note over Store: Shared store = any server can resolve session
Stateless
Stateful
No server-side session; token/cookie carries identity
Server (or shared store) holds session data
Scales horizontally easily; any replica can serve
Need sticky sessions or shared session store
JWT, API keys, OAuth tokens common
Session cookies + server-side session store
Hard to “logout” without token blacklist/short TTL
Logout = delete session in store
REST APIs are usually designed to be stateless so they scale and survive restarts. State (e.g. shopping cart) is often stored in DB or cache and keyed by user/token, not in process memory.