Web 服务状态
我有两个 wcf 服务，它们具有使用 http 绑定托管在 IIS 中的相同接口。两者都只有三个方法：
OpenFile(userid)，用于创建或打开 userid.txt。Write(userid, X)将 X 写入文件Close(userid)关闭文件
InstanceContextMode =InstanceContextMode.PerSession 用于服务 B。
服务A：
它是无状态的（服务在技术上不需要记住用户ID，它由客户端跟踪）还是有状态的（服务操作就像一个状态机。客户端必须以特定的顺序调用方法）？
如果使用 HTTPS 绑定，它是有状态的吗？
服务B：
- 是无状态的，有状态的（因为使用了IIS会话）？
我想一个更普遍的问题是 Web 服务的状态是否取决于它的设计和实现方式或托管方式？是否有类似的“清单”，我可以通过它来确定我的 Web 服务是否被分类为无状态或有状态？
谢谢
I have two wcf services with the same interface hosted in IIS using http binding. Both have only three methods:
OpenFile(userid)which creates or opens userid.txt.Write(userid, X)which writes X into the fileClose(userid)which closes the file
InstanceContextMode =InstanceContextMode.PerSession is used for Service B.
Service A:
Is it stateless (service technically does not need to remember the user id, it's tracked by the client) or stateful (the service operation is like a state machine. Client must call the methods in a particular order)?
If HTTPS binding is used, is it stateful?
Service B:
- Is it stateless, stateful (because IIS session is used)?
I guess a more general question is whether the statefulness of the web service depends on how it's designed and implemented or how it is hosted? Is there like a "checklist" that I can go through to determine if my web service is categorize as stateless or stateful?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
默认情况下，任何通过 HTTP 的内容都是无状态的。当您使用 PerSession 时，它仍然取决于您的 Web 服务实现是否使用 Session。但无论如何，您的 Web 服务器仍然是无状态的，这正是在您在特殊对象（缓存、文件、数据库或会话）中保留状态时发生的。
即使会话也是无状态的：除非服务器在 HTTP 请求中发送 cookie，否则在请求之间不会记住任何内容。
对于 HTTPS，这一点不会改变。虽然它是一个完全不同的协议，但状态性并没有改变。
关于您的清单：它会很短，因为 HTTP 始终是无状态的。无论实现是否维护状态都不会改变这一点。如何解决此限制并保持状态取决于实现，您无法从外部“看到”这一点。
By default, anything over HTTP is stateless. When you use PerSession, it still depends on whether your web service implementations use Sessions. But whatever the case, your web server remains stateless, which is precisely while you retain state in a special object (Cache, File, Database or Session).
Even a Session is stateless: unless the server sends the cookie in the HTTP request, nothing is remembered between requests.
This doesn't change for HTTPS. While it is a completely different protocol, the statefulness doesn't change.
About your checklist: it will be short, as it is always stateless with HTTP. Whether or not an implementation maintains state doesn't change this. It's up to the implementation how to work around this limitation and to maintain state, you cannot "see" that on the outside.