Ian Bicking: the old part of his blog

Re: Rest in more than one request comment 000

Now we're getting somewhere...

Well, it probably looks more like:

action=update&item_3452_amount=0&item_3841_amount=3&item_3841_delete=Delete

Indeed.

I don't think the cart management app will be RESTful, ...

I see what you're saying now. The example above is actually still RESTful in that you're not breaking any hard rules directly (so long as those name/value pairs are in a POST body and not on a GET/URL). I think we're 1.) tripping into the area of taste/style and 2.) trying to determine whether manipulating resources directly is preferable to manipulating resources using what the Atom Publishing Protocol calls "collection resources". e.g. You can post to a "collection resource" and manipulate multiple other resources as a result. There's nothing in REST that disallows or even discourages this that I'm aware of. As you've shown, this is an extremely common practice on the web circa 2006.

I think I'm getting a better idea of the behavior you're labeling cargo cultish though. I don't think it's REST, I think it's more like "individual resource orientedness" or something; the idea that every interaction must be performed through specific individual resources, that interactions on collection resources are "bad style," and that URLs that look like "shopping.com/ianb/cart" offer substantial benefits over URLs that look like "shopping.com/cart.php?user=ianb". I think it's fairly safe to call these principals misguided if not harmful.

... nor do I see any reason it needs to be. It just doesn't matter.

It matters if there's value in interacting with the cart items outside of the one simple cart interface page. For example, if the cart had an "API" or if you wanted a cart that contained items from 5 different shopping sites, or if you just wanted to remove or view cart items on an item-by-item basis, etc. But all of these scenarios require some additional requirement beyond the basic shopping cart page so one could argue that building out a full resource hierarchy is a form of pre-mature optimization and breaks basic principals like Unnessary Until Proven Required.

Overall I think I understand where you're coming from a bit better and I'd agree that the resource based approach should be used because it's valuable, not because it's cool.

Comment on Rest in more than one request comment 000
by Ryan Tomayko