有状态与无状态 Web 服务答案

【问题标题】：Stateful vs. Stateless Webservices有状态与无状态 Web 服务
【发布时间】：2011-02-05 00:18:56
【问题描述】：

想象一个更复杂的 CRUD 应用程序，它具有三层架构并通过 Web 服务进行通信。客户端开始与服务器的对话并执行一些类似向导的操作。为了处理向导，客户端需要服务器提供反馈。

我们开始讨论这种方法的有状态或无状态 Web 服务。我结合自己的经验做了一些研究，这就指向了后面提到的问题。

具有以下属性的无状态网络服务（在我们的例子中）：

+ high scalability
+ high availability
+ high speed
+ rapid testing
- bloated contract
- implementing more logic on server-side

但是我们可以把前两点划掉，我们的应用不需要高扩展性和可用性。

所以我们来到了有状态的网络服务。我已经阅读了很多博客和论坛帖子，实现有状态 Web 服务的最有创意的一点是：

+ simplifies contract (protocol)
- bad testing
- runs counter to the basic architecture of http

但不是几乎所有的 Web 应用程序都有这些缺点吗？ Web 应用程序使用 cookie、查询字符串、会话 ID 和所有东西来避免 http 的无状态。

那么为什么它对 web 服务那么糟糕呢？

【问题讨论】：

【解决方案1】：

因为在 Web 服务中保持状态很困难，而且如果您不是非常小心和/或迟早有经验，您可能会遇到一些很难发现的错误。

【讨论】：

嗯，这取决于平台是什么。很多时候容器会为你处理会话。
为什么不简单地使用为此目的而设计的容器，例如 RDMS。
我不确定我是否理解。如果您将内容放入 RDMS，则基本上意味着滚动您自己的会话，这可能会表现得更差。听起来他不需要会话中的持久信息，那么为什么要把它放在那里呢？
我将状态放入数据库的意思是设计能够从数据库中检索状态的 Web 服务方法。例如，首选网络方法User GetUser(int userId) 而不是User GetUser()，它将在一些定制的状态容器中查找当前用户ID 并返回其信息。由 Web 服务的使用者决定如何处理状态。

【解决方案2】：

我在有状态的 Web 服务方面运气不错。他们确实觉得有点脏，因为 HTTP 之上的空洞 cookie 会话就是这样；但另一方面，它们是肥皂，所以在那个时候对美丽过于沮丧是有点愚蠢的。

要记住的一件事是互操作性：如果您在做有状态的 Web 服务，您的客户端将必须支持与您所做的相同的状态概念（通常是 cookie）。但同样——对我来说效果很好。

附：我假设您在一个容器中，它将为您跟踪会话。

【讨论】：

【解决方案3】：

状态也是大多数错误隐藏的地方。

【讨论】：