Though this is a relatively clean implementation, it still requires the use of persistent
session storage on the server. This is not optimal, for the reasons we discussed
earlier.
In addition, this code could use some architectural cleanup. Because a resource can
be any thing, we will choose to model the cart as a resource itself. Rather than URIs
affecting the product, which have effects on the cart in the session, we choose
URIs that explicitly model their effects on our newly created cart resource. Using
some standard RESTful Rails URI conventions, we come up with the following set of
actions.
200 | Chapter 7: REST, Resources, and Web Services
Note that our old code has no action for ???create cart,??? but the new code requires that
as an explicit step. This is a consequence of RESTful design; we now realize that the
cart resource (along with its child, the cart-product or line-item resource) is a separate
resource and should be treated as such. Rather than treating cart creation as a
side effect of some other action, we explicitly make cart creation a client-initiated
action.
Also notice that the old code has RPC-style URIs; they contain the method name.
The new URIs have a more proper separation of concerns. The HTTPmethod
contains the verb or action; the URI contains the name of the object of that action
(the resource); and the optional request body contains information pertaining to the
resource.
Pages:
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313