Ian Bicking: the old part of his blog

Rest in more than one request comment 000

and so they worry about what the URI for the delete action looks like.

The delete action doesn't have a URL - the item has a URL. The delete action is an interaction and it looks like this with AJAX/other capable HTTP client libraries:

DELETE http://shopping.com/cart.php?user=ianb&item=3452 HTTP/1.1

It looks like this with forms:

POST http://shopping.com/cart.php?user=ianb&item=3452 HTTP/1.1


Well, it probably looks more like:

POST http://shopping.com/cart.php?user=ianb HTTP/1.1


Or whatever other details come from the way the HTML form is designed. Oldschool HTML forms are okay, but they do often mean tight coupling between the form and the action. So the RESTful, stable interface isn't the delete action (at least not the one the management app uses), it's some other interface.

See, this is where I'm getting the feeling that you've been reading the wrong material on REST. If you're reading stuff that says REST is about "invoking services" using name/value pairs instead of posting XML (WS), then that shit is just wrong. I don't understand where the insinuation that the client is just a "viewer" or that the server is exposing "services" is coming from. None of this is based in REST. REST is all about simple resource representations, identified by unique identifiers (URLs), interlinked using references to each other, and manipulated using a small and universal set of basic verbs. REST is "resource oriented", not "service oriented". There's no concept of a "service", it's resources all the way down.

I don't think the cart management app will be RESTful, nor do I see any reason it needs to be. It just doesn't matter. It doesn't really matter what the HTML forms are that the cart management uses. When you check out, you redirect the user to that app. When they are finished managing, the management app redirects them to the next step. What happens between those doesn't matter. Nobody should care if the management app uses RESTful principles internally.

Browser-based APIs are more concerned about where the browser goes, not what it sees.

Comment on Re: REST in more than one request
by Ian Bicking


Well... maybe I didn't figure out quite what my point was there. The point of a cart management app is that it speaks to the browser, it speaks POST and HTML. It interacts. It's not an atomic resource, it's really an interactive application that speaks to a browser. There's no resource there.

# Ian Bicking

Now we're getting somewhere...

Well, it probably looks more like:



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.

# Ryan Tomayko