How do I make my Web Application stateless yet still do something useful?
I've seen this advice...
ideally the web should follow the REST principle and be completely stateless. Therefore a single URL should identify a single resource, without having to keep the navigation history of each user.
...and I read the Wikipedia page http://en.wikipedia.org/wiki/REST and it really sounds good, but I don't get how to actually implement it. I'm working in ASP .NET Webforms NOT MVC.
For example, in the application I am about to build - I need my user to Login before I allow them to do anything. There are a couple of hoops they have to jump through before they are allowed to do much useful - like Accept T's and C's and confirm their basic details are unchanged. Finally they are allowed to do something they really want like BuyAProduct!
It seems to me (I come from the HEAVILY stateful world of the Rich client) that I need state to record what they have done and infer from that what they are allowed to do. I don't see how I can support them (say) bookmarking the BuyAProduct URI. When they arrive at the bookmark how do I know if they have logged in and if they agreed to the T's and C's and if they dutifully checked their basic details?
I love the idea of the app being stateless, partly because it seems to completely solve the problem of "What the heck do I do when the user clicks on the Back and Forward buttons?" I don't see how I can still get it to work properly. I feel I am missing something really fundamental about this.
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!
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.
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.
链接地址: http://www.djcxy.com/p/41138.html