REST (Representational State Transfer) is an architectural style for building web services. There are six guiding constraints that define a RESTful web service:
Client-Server
There should be a separation between the client and the server. This means the UI and data storage concerns are separate. The client handles the UI while the server handles data storage.
Stateless
No client session state is stored on the server between requests. The session state is stored on the client. Each request has all the necessary information to complete the request and no session data is stored on the server.
Cacheable
REST responses should indicate if they are cacheable or not. This allows clients and intermediaries like proxies and CDNs to cache responses when applicable to improve performance.
Uniform Interface
There should be a uniform interface between the client and server consisting of:
- Resource identification through URIs
- Resource manipulation through representations
- Self-descriptive messages
- Hypermedia as the engine of application state (HATEOAS)
Layered System
Client and server can be decomposed into hierarchical layers to improve scalability and flexibility.
Code on Demand (optional)
Servers can optionally provide executable code to clients. For example, JavaScript sent to a browser.
The Stateless Constraint
Out of the core REST constraints, the stateless constraint essentially prohibits the use of cookies in a RESTful API. This constraint requires that each request from the client must contain all necessary information to complete the request and no session state is stored on the server between requests.
Cookies are used to store session data on the client side. The server can put a cookie on the client, and when the client makes subsequent requests it will include that cookie allowing the server to access the session data. With REST’s stateless constraint, session state must be handled entirely on the client side without storing anything on the server between requests.
Why Stateless?
There are several benefits to keeping REST APIs completely stateless:
- Improved reliability – No need to restore or manage session state on server failures
- Better scalability – Requests can be distributed across servers more efficiently
- Higher performance – Not having to fetch session state for every request
- Easier caching – Requests can be cached as all necessary info is there
Solutions Without Cookies
There are a number of solutions for adding session state to a REST API without using cookies:
Tokens
An authentication token can be generated and returned to the client on login. The client then sends this token with every subsequent request. The token contains session data encrypted in it.
URI parameters
Session IDs can be passed in the URI for each REST request instead of using a cookie.
HTTP Header
A custom HTTP request header can be used to pass the session ID or other session data.
Server-side session storage
The server can still maintain session state but it must not be tied to a specific client. The client still passes all necessary session data with each request.
Examples of Stateless APIs
Many well-designed REST APIs are completely stateless. Here are some examples:
GitHub API
The GitHub API uses tokens rather than cookies for authentication and session handling. All session data is contained within generated tokens.
Stripe API
The Stripe API also uses tokens for managing sessions statelessly.
AWS REST APIs
Amazon’s AWS REST APIs are stateless and use query parameters or headers to pass authentication and session IDs.
When to Use Cookies
While stateless REST APIs have advantages, maintaining session state on the server side with cookies can also be appropriate in some cases. Reasons you may want to use cookies include:
- Easier to implement sessions
- Want sticky sessions to same backend server
- Require very large session data
- Need to store sensitive session data server-side
So in summary, the stateless constraint is what prohibits the use of cookies in a strictly RESTful API. But not all APIs need to follow REST principles 100%. There are trade-offs to consider for your specific use cases.
Conclusion
The stateless constraint of REST prevents the server from storing any client session data between requests. This essentially prohibits the use of cookies, as cookies store session data on the client that gets sent back to the server. There are other solutions like tokens that allow session state to be maintained fully on the client side. Overall the REST approach of being completely stateless has advantages for reliability, scalability, and caching even if it means jumping through extra hoops for session management.