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 application
servers to be treated as black boxes from an architectural perspective. In Rails,
this is often called shared-nothing architecture. If each request is independent of session
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 servers,
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 is sticky sessions, directing
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.
Pages:
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310