What Is REST? | 197From an HTT Pperspective, it would seem rather odd that another mechanism
would have to be introduced for authentication. HTT Palready provides methods for
authenticating users, and they work statelessly.
However, the standard HTT PBasic and Digest authentication mechanisms have
many problems, and they are rarely used on the public Web. There are several fac-
tors affecting their widespread adoption:
- They use the standard browser/operating system controls to prompt for creden-
tials; they cannot be styled. - They do not easily facilitate logout.
- There is no easy way to request login conditionally, or return different represen-
tations based on whether or not the user is logged in. - HTT PBasic authentication does not really even attempt to hide the username
and password when transmitting across the network; in Base64 encoding, they
are essentially plain text. Digest authentication is much more secure, but is not
universally supported in older browsers.
Thus, a web application requiring authentication usually presents login forms itself
and keeps track of user authentication using a cookie. Most implementations of this
run contrary to the principles of REST by keeping additional application state out-
side of the request envelope. The cookie itself is stored and transmitted just like an
HTT Pauthentication request would be, but the difference is that authentication
cookies usually gain their validity from being tied to server-side application state.
Why statelessness?
Statelessness, and its application to web sites and web applications, is often a point
of contention, even among REST’s adherents. Though most developers agree that
minimizing the amount of application state carried on the server is a useful goal, it is
not always clear to what degree the principles should be carried.
The primary benefit of statelessness is that it enables scalability by allowing applica-
tion servers to be treated as black boxes from an architectural perspective. In Rails,
this is often calledshared-nothingarchitecture. If each request is independent of ses-
sion state, it does not matter whether the subsequent requests in a browsing session
are handled by one server or 1,000. In an architecture with 1,000 application serv-
ers, the only communication between the servers is made by changing state in the
resources themselves (typically through a database or filesystem).
Contrarily, in an environment that requires server-side session state, there are two
options. The servers can directly communicate and discuss the session state, which
introduces another interface; besides dealing with resource state, servers must also
communicate about application state. The other option issticky sessions, direct-
ing the load balancer to funnel all requests from the same session to the same
application server. This can work well, and it eliminates the need for backend
server communication. Avi Bryant (of Seaside fame) endorses this architecture.