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
A cookie would seem to be the answer to your question. You can use the the .net authentication provider which will set a cookie, that your application can check for and require the presence for if they're to buy anything.
The thing you want to try and avoid is keeping a state representation of them on the server, aka session cookie. That will make scaling more difficult.
It is okay to maintain resource state. The "stateless prohibition" just refers to session state.
Here's an excerpt from Roy Fielding's seminal REST derivation:
We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
The advice isn't suggesting that the app should be stateless - it's suggesting that the resources in the app should be stateless. That is, a page called "www.mysite.com/resources/123" will always represent the same resource, regardless of which user is accessing it or whether they're logged in or not.
(The fact that you might deny a non-logged-in user access is a separate issue - the point is that the Uri itself doesn't rely on user-specific data to work.)
For example, the kind of sites that break this rule are those where you navigate to a product page, email the Uri to your friend, and on clicking it they see a message along the lines of "I'm sorry, your session has expired" or "This product does not exist" or similar. The reason this happens is because the Uri includes something specific to the user's session on the site, and if a different user tries to use the link (or the same user at a later time), it's no longer valid.
So, you will always still need some form of state for your application, but where that state is implemented is the important factor.
Hope that helps shed a little light!
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).
If you want to do Web forms, that's cool. If you want to do REST that's cool too. But please for the love of everything sacred, please don't attempt to adhere to the principles of REST using Web Forms.
Just to clarify this point further, I don't believe webforms is a wise choice for REST because the conceptual model that WebForms is based on is one where you abstract away the web. It was built to emulate the VB development model.
REST embraces HTTP and the distributed nature of web applications. The two approaches are not compatible.