如何使我的Web应用程序变为无状态,但仍然可以做一些有用的事情?

如何使我的Web应用程序变为无状态,但仍然可以做一些有用的事情?

问题描述:

我已经看到了这个建议...

I've seen this advice...

理想情况下,Web应该遵循REST原则并且完全无状态.因此,一个URL应该标识一个资源,而不必保留每个用户的导航历史记录.

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.

...并且我阅读了Wikipedia页面 http://en.wikipedia.org/wiki/REST 听起来确实不错,但是我不知道如何实际实现它.我正在ASP.NET Webforms NOT MVC中工作.

...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.

例如,在我要构建的应用程序中-我需要我的用户登录后才能允许他们执行任何操作.在允许它们做很多有用的事情之前,必须绕过几圈-像接受T和C并确认其基本细节不变.最后,他们被允许做他们真正想要的事情,例如BuyAProduct!

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!

在我看来(我来自Rich客户的有状态世界),我需要状态来记录他们所做的事情,并从中推断出他们被允许做的事情.我看不到如何为他们(例如)添加BuyAProduct URI书签.当他们到达书签时,我怎么知道他们是否已登录以及他们是否同意T和C,以及他们是否忠实地检查了其基本详细信息?

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.

建议不是建议 app 应该是无状态的-它建议应用程序中的资源应该是无状态的.也就是说,一个页面"www.mysite.com/resources/123"将始终代表相同的资源,而不管是哪个用户正在访问它,或者是否已登录.

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.

(您可能会拒绝非登录用户访问的事实是一个单独的问题-关键是Uri本身并不依靠特定于用户的数据来工作.)

(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.)

例如,违反此规则的网站是那些您导航到产品页面,将Uri通过电子邮件发送给您的朋友的网站,并且在单击该网站时,他们会看到一条消息,内容为:对不起,您的会话已过期"或此产品不存在"或类似内容.发生这种情况的原因是,Uri包含网站上用户会话的特定内容,并且如果其他用户尝试使用该链接(或稍后使用同一用户),则不再有效.

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!