有状态与无状态 Web 服务 [英] Stateful vs. Stateless Webservices

问题描述

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

Imagine a more complex CRUD application which has a three-tier-architecture and communicates over webservices. The client starts a conversation to the server and doing some wizard like stuff. To process the wizard the client needs feedback given by the server.

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

We started a discussion about stateful or stateless webservices for this approach. I made some research combined with my own experience, which points me to the question mentioned later.

具有以下属性的无状态网络服务(在我们的例子中):

Stateless webservices having the following properties (in our case):

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

但我们可以去掉前两点，我们的应用程序不需要高可扩展性和可用性.

But we can cross out the first two points, our application doesn't needs high scalability and availability.

所以我们来到有状态的网络服务.我读过很多博客和论坛帖子，实现有状态网络服务的最有创意的一点是:

So we come to the stateful webservice. I've read a bunch of blogs and forum posts and the most invented point implementing a stateful webservice was:

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

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

But doesn't almost all web applications have these bad points? Web applications uses cookies, query strings, session ids, and all the stuff to avoid the statelessness of http.

那么为什么它对网络服务如此不利?

So why is it that bad for webservices?

推荐答案

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

Because keeping state in a webservice is difficult and if you aren't extremely careful and/or experienced sooner or later you might hit some very difficult to find bugs.

这篇关于有状态与无状态 Web 服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！