我是否应该支持除 RESTful HTTP 之外的任何内容？
我正在为我公司的 CRM 软件开发基于 WCF 的 API。 未来将用于开发多平台应用程序。 我知道 WCF 提供命名管道、TCP 和 HTTP 传输，但是当现在一切似乎都在使用 RESTful HTTP 时，我是否应该为支持这三种传输的复杂性而烦恼呢？
I'm developing a WCF-based API for my company's CRM software. In the future, it will be used to develop applications on multiple platforms. I know WCF provides named pipe, TCP, and HTTP transports, but should I bother with the complexity of supporting all three when everything seems to be using RESTful HTTP these days?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
REST 是 Web 的架构风格，而不仅仅是没有 SOAP 的 HTTP 上的 xml 文件。
WCF 是一个框架，其唯一目的是将开发人员从底层平台/协议/规范堆栈中抽象出来。 WCF REST 是对工具包的一个糟糕补充，无法让您公开 POX 服务。
RESTful 要求分布、缺乏会话、设计自定义媒体类型或重用现有媒体类型，以及您需要考虑的许多其他属性。 设计 REST 架构与基于 rhttp 的 xml 的关系就如同设计 SOA 架构与肥皂信封的关系一样。
REST is the architectural style of the web, not just xml files over htttp without SOAP.
WCF is a framweork with the sole purpose in life is to abstract developers from the underlying platform / protocol / stack of specs. WCF REST was a poor addition to the toolkit to let you expose POX services.
RESTfulness requires distribution, lack of session, designing of custom media types or reuse of existing ones, and many other properties you need to think about. Designing a REST architecture is as much about xml ove rhttp as designing an SOA one is about having a soap envelope.
为简单起见，HTTP 传输将是使用最广泛、最具灵活性的传输。 它也可能适用于几乎所有情况。 请注意，涉及开销，因此它不是最快的。 总是存在权衡。
For simplicity, HTTP transport would be the most widely used transport with the most amount of flexibility. It also will likely work in almost all situations. Note that there is overhead involved so it isn't the fastest. There's always tradeoffs.
您在没有意识到的情况下问了两个不同的问题。
第一个问题是，我应该使用什么传输方式——HTTP、TCP 还是命名管道？ 由于您是从头开始构建新服务，因此我建议使用 HTTP 作为传输，因为您的服务将更容易通过防火墙。 其他传输类型主要用于简化与可能不理解 HTTP 的其他服务和客户端的通信。
第二个问题是，我应该使用什么风格的 HTTP Web 服务？ 我应该采用 WS-* 堆栈吗？ /en.wikipedia.org/wiki/Xml-rpc" rel="nofollow noreferrer">XML-RPC 模式，纯旧 XML (POX)，或 RESTful 方法？ 这是一个更复杂的问题。
WCF 使 ws-* 和 XML-RPC 样式变得简单。 使用 WCF 配置 POX 风格的 Web 服务有些棘手。 使用 WCF 构建真正的 RESTful 服务相当困难——您必须了解 WCF 工作原理的基础知识并禁用它为您执行的一些“魔法”。
我认为RESTful架构风格简单且经过验证，是一个不错的选择。 但很难配置 WCF 以正确支持它。 如果您使用 WCF 作为平台，请考虑使用其他样式之一。
You've asked two different questions without realizing it.
The first question is, what transport should I use -- HTTP, TCP, or named pipes? Since you're building a new service from scratch, I'd suggest using HTTP as the transport since your service will have a much easier time getting through firewalls. The other transport types are used primarily to simplify communication with other services and clients that might not understand HTTP.
The second question is, what style of HTTP web service should I use? Should I adopt the WS-* stack, an XML-RPC pattern, plain old XML (POX), or a RESTful approach? This is a more complicated question.
WCF makes the ws-* and XML-RPC styles easy. The POX style of webservice is somewhat tricker to configure using WCF. Building a truly RESTful service using WCF is quite hard -- you'll have to understand the fundamentals of how WCF works and disable some of the "magic" that it performs for you.
I think the RESTful architecture style is simple and proven, and a good choice. But it's difficult to configure WCF to support it properly. If you're tied to WCF as your platform, consider using one of the other styles.
我有一段时间没有看过 Indigo，但据我记得，有一些东西 RESTful HTTP 不支持并且没有类似的东西，比如 WS-Transactions、WS-Security 等等。 如果您需要这些，则必须切换到 SOAP。 如果没有，REST 对于您的公司来说应该足够了。
还有性能问题。 通过 TCP 或命名管道编码为二进制 XML 的 SOAP 比通过 HTTP 的文本 XML 快一些。
另一方面，在大多数情况下添加 TCP 和命名管道几乎是微不足道的，并且成本主要围绕应用程序服务器的部署和配置。
所以，我不会从一开始就把这两个排除在外。 在需要之前我也不会将它们添加为功能。 不过，我要做的是确保 SOAP 和 REST over HTTP 都能正常用于该服务，以便我可以选择在将来需要时进行扩展。
I have not looked at Indigo in a while, but as far as I remember, there are some things that RESTful HTTP does not support and has no analog, like WS-Transactions, WS-Security and couple others. If you need these, you'll have to switch to SOAP. If not, REST should be good enough for your company.
There's also the question of performance. SOAP encoded as binary XML over TCP or named pipe offers will be a bit faster than text XML over HTTP.
On the other hand, adding TCP and named pipes for the most parts is almost trivial and the cost is mostly around te deployment and configuration of the app server.
So, I wouldn't rule these two out of question from the start. Nor would I add them as features until needed. What I'd do though is to make sure both SOAP and REST over HTTP work properly for the service, just so that I have the option to expand in future if required.
一般来说，您的 WCF 组件不应与任何内容耦合，包括传输、安全以及其他协议和技术。 最终目标（可能还不是 100% 可能）是编写一次服务接口和实现，然后能够在任何类型的环境中通过任何协议以任何类型的安全性使用它们。 所有这些都可以在您的配置文件和客户端应用程序中定义。
In general your WCF components shouldn't be coupled to anything including transport, security, and other protocols and technologies. The ultimate goal (probably not 100% possible yet) would be to write your service interface and implementation once and then be able to use them in any sort of environment over any protocol with any sort of security. All of that can be defined in your configuration files and in your client apps.