I\'ve seen this advice...
ideally the web should follow the REST principle and be completely stateless. Therefore a single URL should identify a singl
Here's the thing: REST is about stateful communications over a stateless protocol. It's not that REST is stateless. WebForms enables you to retain state between requests. Why is that necessary? It let's you do things like sort items on a list with up/down buttons without having to update the underlying resource with each click. You don't need that. You could just PUT the resource representation so that it looks correct or use JavaScript to edit your representation and then do a PUT at the end once you are satisfied. (Note that I used PUT, not POST. What you are really doing is replacing the representation so that future GETs retrieve the right state.)
WebForms uses POST for everything. You should only POST to a URL when you are creating a new item and don't know where it will live. If you know its url, then you should use PUT to create or replace. If you need intermediary steps for, say, a shopping cart, then you should create resource representations for those intermediary steps. Your browser and server communicate by passing full representations between each other. It's simple request/response message passing.
WebForms doesn't encourage this. You can build RESTful systems in WebForms, but the default model will push you away from it towards a RPC approach. I can think of two ways around this: Front Controller (in which case you should really consider MVC) or using .ashx files for almost everything. The Postback model pretty well obliterates any real hope of doing true REST with real WebForms/.aspx (i.e. PUT and DELETE are always POSTs and thus fail the REST model).