WCF Web Api 与 WebHttpBinding
我是 WCF RESTFull 服务开发的新手，我正在寻找一些有用的信息以及您关于使用 webHttpBinding 与新的 WCF Web API http 的体验反馈://wcf.codeplex.com/。
我想要了解 webHttpBinding 的缺点，以及为什么要使用新的 Web api，特别是新的 API 解决了哪些问题。 如果您能给我指出一些比较两者的博客文章，或者只是谈论使用 webHttpBinding 时的问题，我将不胜感激。先感谢您。
I'm new to WCF RESTFull services developpment and I'm looking for some usefull information and your experience feedback about using webHttpBinding compared to the new WCF Web API http://wcf.codeplex.com/.
What I'm looking for is to know about the shortcomings of webHttpBinding and therefore why to use the new Web api and especially what problems the new API resolves.
If you could point me to some blog posts comparing both of them or just talking about the problems when using webHttpBinding I would appreciate. Thank you in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想说的主要缺点是 webhttpbinding 使得处理 HTTP 特定问题变得困难。如果您所做的只是通过 HTTP 传递一个序列化为 XML 或 JSON 并且可以通过不同格式传输的对象，那么它会非常有效。
HTTP 不仅仅是 XML 和 JSON 的简单传输协议，它是具有丰富语义的应用层协议。 Web API 专门针对那些想要通过 HTTP 构建系统以充分利用 HTTP 丰富性的人们。
Web API 允许 HTTP 资源根据不同客户端的需求拥有多种表示形式。该范围的一端可能是一个愚蠢的浏览器，它仅使用表单 url 编码的帖子和 GET 与服务对话，而另一端可能是使用 Atom/OData 或基于超媒体的媒体类型的更丰富的客户端。 Web API
Web API 接受其他 HTTP 特定问题，例如 conneg、etags 等，这些问题可以更好地利用中间 Web 服务器。
Web API 的设计考虑了更多的可测试性，因此您可以以更可测试的方式解决 HTTP 消息或其他问题的工作。
Web API 具有更简化的配置故事。
您可以在此处阅读有关基本原理的更多信息：http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx
Main shortcomings I would say is that the webhttpbinding makes it difficult to handle HTTP specific concerns. It works great if all you are doing is passing an object over HTTP that is serialized into XML or JSON and which may be transported over different formats.
HTTP is much more than a simple transport protocol for XML and JSON, it is an application layer protocol with rich semantics. Web API is specifically targetting folks that want to build systems over HTTP that fully levergage HTTP's richness.
Web API embraces that HTTP Resources can have a multitude of representations based on the needs of different clients. One end of the spectrum could be a dumb browser that just talks to a service using a Form url encoded post and a GET, while the other end could be a more rich client that uses Atom/OData or a hypermedia based media type.
Web API embraces that there are other HTTP specific concerns like conneg, etags, etc which allow better leveraging intermediary web servers.
Web API is designed with more testability in mind, thus you can address working with HTTP messages or other concerns in a more testable manner.
Web API has a more simplified configuration story.
You can read more about the rationale here: http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx
对我来说最重要的区别是编程模型的变化。您不再编写暴露与 HTTP 习惯用法（GET、POST 等）绑定的“操作”的“服务”。使用 Web API，您可以创建客户可以与之交互的“资源”(POCO)。
Web API 似乎更擅长处理各种自定义媒体类型（例如 PNG 图像）。
最后但并非最不重要的一点是，Web API 更适合自动化测试。例如，您不再需要使用静态上下文类来访问 HTTP 概念（例如响应代码）。您使用 POCO 请求和响应类，可以使用旧式 new() 运算符在自动化测试中轻松实例化它们。
我同意 Ladislav 的观点，即 Web API 现在只是一个预览版，在其之上构建应用程序可能既存在风险，又会被许可协议所禁止（但我还没有检查过）。
您考虑过 @serialseb 的 OpenRasta 吗？它很稳定，并为构建 RESTful 服务提供了非常好的编程模型。
The most significant difference for me is the change in programming model. You no longer write 'services' which expose 'operations' bound to HTTP idioms (GET, POST etc.). With Web APIs you create 'resources' (POCOs) with which your clients can interact.
Web APIs seem to be better at handling various custom media types (like PNG images for example).
Last but not least, Web APIs are far better suited for automated testing. For instance, you no longer have to use static context classes to access HTTP concepts such as response codes. You use POCO request and response classes which can be easily instantiated in automated tests using old-style new() operator.
I agree with Ladislav that Web APIs are just a preview now and building application on top of it can be both risky and forbidden by the means of license agreement (but I haven't checked that).
Have you considered @serialseb's OpenRasta? It is stable and offers very nice programming model for building RESTful services.
Web API 类似于 WCF 中 REST 开发的可能未来。它只是预览版，在最终发布之前（可能在 .NET 框架的下一版本中）可能会发生重大变化。因此，如果您想构建生产 REST 服务，您应该使用 webHttpBinding。
有关 Web Api 的可用信息例如可以在 .NET Connected 上找到框架团队的博客以及您提到的网站上。它是当前REST API的简化和扩展。
The Web API is something like possible future of REST development in WCF. It is just preview which can significantly change before final release (probably in next version of .NET framework). So if you want to build production REST service you should use webHttpBinding.
Available information about Web Api can be found for example on .NET Connected Framework team's blog and on the site you mentioned. It is simplification and extension of current REST API.
Web API 提供基于 REST 友好的 HTTP API。 Web API 使用 MVC 模式，并且 ASP.NET MVC 开发人员将会非常熟悉。 Web API 可以利用 HTTP 作为应用层协议的功能，根据客户端的请求标头以多种表示形式（XML、JSON、HTML 等）返回资源。
另一方面，WCF webHttpBinding 使用 WCF 的模式，并且将更吸引 WCF 开发人员 - ServiceContracts、OperationContracts、全面（或超重，取决于您如何看待它、配置文件）、在外部自行托管的能力IIS。
我喜欢 Web API 的原因之一是能够使用动态类型来逃避类型系统的约束。我还喜欢 Web API 中的默认异常行为 - 对比 WCF webHttpBinding，默认情况下，异常以 HTTP 500 + HTML 负载的形式出现（yuk！）。
很高兴在这里可以在两种出色的技术之间进行选择。我不会将 Web API 描述为比 WCF“更新”或“更好”，因为这意味着它是一种替代技术，并且 WCF webHttpBinding 是遗留技术，我不认为这是真的。
我最近选择使用 WCF webHttpBinding 为现有 WCF SOAP 服务公开 JSON API。我相信这是一个不错的选择，因为它适合现有解决方案的风格并最大限度地减少了所需的更改量。
Web API provides a REST-friendly HTTP based API. Web API uses the patterns of MVC and is going to be very familiar to ASP.NET MVC developers. Web API can leverage the capabilities of HTTP as an application layer protocol, returning resources in multiple representations (XML, JSON, HTML etc.) according the the client's request headers.
On the other hand WCF webHttpBinding uses the patterns of WCF, and is going to appeal more to the WCF developer - ServiceContracts, OperationContracts, comprehensive (or overweight, depending how you look at it, config file), ability to self-host outside of IIS.
One of the things I like about Web API is the ability to use dynamic types to escape the constraints of the type system. I also like the default exception behavior in Web API - contrast WCF webHttpBinding where, by default, exceptions bubble up as HTTP 500 + an HTML payload (yuk!).
Its nice to have the choice between two excellent technologies here. I wouldn't describe Web API as 'newer' or 'better' that WCF, as this implies its a replacement technology and that WCF webHttpBinding is legacy, which I don't believe is true.
I chose to use WCF webHttpBinding recently to expose a JSON API for an existing WCF SOAP service. I believe it was a good choice because it fitted that style of that existing solution and minimized the amount of change required.