How come server is supposed to cache information in REST APIs?

Viewed 1527

According to this in property 3 and property 4,

Stateless

Roy fielding got inspiration from HTTP, so it reflects in this constraint. Make all client-server interactions stateless. The server will not store anything about the latest HTTP request the client made. It will treat every request as new. No session, no history.

No client context shall be stored on the server between requests. The client is responsible for managing the state of the application.

But then again,

In REST, caching shall be applied to resources when applicable, and then these resources MUST declare themselves cacheable. Caching can be implemented on the server or client-side

How is the server being stateless if it can cache information?

2 Answers

tldr: Stateless refers the behavior of a server to not record any information on the client's behalf between calls.

Caches are used as a server optimization strategy for resources that are requested often (and do not change frequently).


If a server is "stateless" this mean that no information will be held on the server side on the clients behalf between requests. Thus each request that a client makes must contain all of the required information for the server to perform the desired action. Irrespective of how many calls the client has made on this server previously.

Stateless means there is no memory of the past. Every request is performed as if it were being done for the very first time.

Stateful means that there is memory of the past. Previous request are remembered and may impact behavior of the current Request

Caching is merely holding a copy of a resource that the server is responsible of serving. Caching is commonly used for highly requested resources. Caching strategies can be used by both stateless and stateful services.

In REST when designing an api, you can have Stateless iteration with your clients and you can use caching to store highly requested items in memory to save IO calls to disk.

The authoritative reference for REST is Fielding's dissertation.

Fielding's definition of stateless is found in the discussion of network-based architectural styles

The client-stateless-server style derives from client-server with the additional constraint that no session state is allowed on the server component. 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 kept entirely on the client.

It may help to contrast this idea with FTP, where the server is expected to track session state.

RETR example.txt

In FTP, to interpret that RETR command correctly, you need to know what the current working directory is for the session, and the clues that tell you that are stored in earlier messages.

Because HTTP requests are self contained, you don't need "sticky" session management.

As Fielding himself notes, Cookies violate the stateless rest constraint:

The same functionality should have been accomplished via anonymous authentication and true client-side state.

Related