Avi Bryant (of Seaside fame) endorses this architecture.
198 | Chapter 7: REST, Resources, and Web Services
However, it eliminates the possibility of high availability (sessions cannot be shared
between two servers unless they communicate), and a server that is restarted typically
loses its sessions (unless storing them in persistent storage, which negates many
advantages of sticky sessions). Neither of these options is terribly RESTful, and so we
promote statelessness as far as is practical.
Resourceful session state: An example
So what is the RESTful alternative to holding session state on the server? As with
nearly any problem REST developers face, the solution is to model it as a resource.
With the exception of authentication information (discussed later in the chapter),
nearly anything that would be stored in a session could also be factored into a
resource.
Consider the example of a shopping cart. A typical, simple, non-RESTful Rails
implementation would look something like this:
app/models/cart.rb
# A simple Hash that defaults to zero.
# Used to map product IDs to quantities to represent a shopping cart.
class Cart < Hash
def initialize
super(0)
end
end
app/controllers/carts_controller.rb
class CartsController < ApplicationController
before_filter :set_cart
def add_product
product_id = params[:id]
quantity = params[:quantity] || 1
# Increment cart quantity by provided quantity
session[:cart][product_id.
Pages:
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311