It cannot
be shared or bookmarked.
At the lower levels, application state includes HTTPcookies, which can break REST
in lesser or greater amounts. At the higher levels, web application frameworks (Rails
included) often expose a session persistence mechanism. Typically, a repository of
session state is kept on the server, indexed by a key that is given in an HTTPcookie
to the client.* This is much more self-evidently an application state repository.
* Newer versions of Rails default to a cookie-based session store, which stores the entire session, not just an
index, in the cookie. This has several advantages, but also some security concerns. I discuss the trade-offs in
Chapter 5.
196 | Chapter 7: REST, Resources, and Web Services
REST maintains that all application state should be kept on the client. This is what is
meant by statelessness; not that there is no state within the application, but that each
request can stand on its own; the client/server session itself maintains no state.
HTTP state
Let??™s examine how state is typically dealt with in web applications. HTTPprovides
cookies as a method for servers to persist small amounts of data on the client. Like
all protocols in layered systems, HTTPuses lower-level (stateless) primitives to build
higher-level (stateful) abstractions. Here, we??™ll examine the mechanics of that
process.
By default, unless sessions are manually disabled, Rails sets up a new session on a
client??™s first interaction with the application.
Pages:
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307