15

我看过这个建议...

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

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

例如，在我即将构建的应用程序中——我需要我的用户登录，然后才能允许他们做任何事情。在允许他们做很多有用的事情之前，他们必须跳过一些障碍——比如接受 T 和 C，并确认他们的基本细节没有改变。最后，他们被允许做他们真正想做的事情，比如 BuyAProduct！

在我看来（我来自富客户端的大量有状态世界）我需要状态来记录他们所做的事情并从中推断出他们被允许做什么。我看不出我如何支持他们（比如）为 BuyAProduct URI 添加书签。当他们到达书签时，我如何知道他们是否已登录以及他们是否同意 T 和 C 以及他们是否尽职尽责地检查了他们的基本详细信息？

我喜欢应用程序无状态的想法，部分原因是它似乎完全解决了“当用户单击后退和前进按钮时我该怎么办？”的问题。我不知道如何才能让它正常工作。我觉得我错过了一些关于这一点的真正基本的东西。

4

5 回答 5

23

该建议并不是建议应用程序应该是无状态的 - 它是建议应用程序中的资源应该是无状态的。也就是说，名为“www.mysite.com/resources/123”的页面将始终代表相同的资源，无论哪个用户正在访问它或他们是否登录。

（您可能拒绝未登录用户访问的事实是一个单独的问题 - 关键是 Uri 本身不依赖于用户特定的数据来工作。）

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

因此，您的应用程序仍将始终需要某种形式的状态，但实现该状态的位置是重要因素。

希望这有助于阐明一点！

于 2010-06-10T16:35:18.067 回答
12

如果你想做 Web 表单，那很酷。如果你想做 REST，那也很酷。但是，出于对一切神圣事物的热爱，请不要尝试使用 Web 表单来遵守 REST 的原则。

为了进一步阐明这一点，我不认为 WebForms 是 REST 的明智选择，因为 WebForms 所基于的概念模型是您将 Web 抽象出来的模型。它是为模拟 VB 开发模型而构建的。

REST 包含 HTTP 和 Web 应用程序的分布式特性。这两种方法不兼容。

于 2010-06-11T00:01:47.720 回答
3

可以保持资源状态。“无状态禁止”仅指会话状态。

以下是Roy Fielding 开创性的 REST 推导的摘录：

我们接下来为客户端-服务器交互添加一个约束：通信本质上必须是无状态的，如第 3.4.3 节（图 5-3）中的客户端-无状态-服务器（CSS）样式，这样从客户端到的每个请求服务器必须包含理解请求所需的所有信息，并且不能利用服务器上存储的任何上下文。因此，会话状态完全保留在客户端上。

于 2013-06-01T23:16:39.670 回答
1

事情是这样的：REST 是关于通过无状态协议进行的有状态通信。这并不是说 REST 是无状态的。WebForms 使您能够保留请求之间的状态。为什么这是必要的？它让您可以使用向上/向下按钮对列表中的项目进行排序，而无需在每次单击时更新底层资源。你不需要那个。您可以只 PUT 资源表示以使其看起来正确，或者使用 JavaScript 编辑您的表示，然后在您满意后在最后执行 PUT。（请注意，我使用的是 PUT，而不是 POST。您真正要做的是替换表示，以便将来的 GET 检索正确的状态。）

WebForms 对所有事情都使用 POST。当您创建一个新项目并且不知道它会在哪里时，您应该只发布到一个 URL。如果你知道它的 url，那么你应该使用 PUT 来创建或替换。如果您需要购物车的中间步骤，那么您应该为这些中间步骤创建资源表示。您的浏览器和服务器通过在彼此之间传递完整表示进行通信。这是简单的请求/响应消息传递。

WebForms 不鼓励这样做。您可以在 WebForms 中构建 RESTful 系统，但默认模型会将您从它推向 RPC 方法。我可以想到两种解决方法：前端控制器（在这种情况下，您应该真正考虑 MVC）或使用 .ashx 文件来处理几乎所有内容。Postback 模型很好地消除了使用真正的 WebForms/.aspx 进行真正 REST 的任何真正希望（即 PUT 和 DELETE 始终是 POST，因此使 REST 模型失败）。

于 2010-06-11T06:55:52.273 回答
1

cookie 似乎是您问题的答案。您可以使用将设置 cookie 的 .net 身份验证提供程序，您的应用程序可以检查该 cookie 并要求他们在购买任何东西时存在。

您要尝试避免的事情是在服务器上保留它们的状态表示，即会话 cookie。这将使扩展更加困难。

于 2010-06-11T08:06:20.303 回答