今天在 .NET 中实现 RESTful 架构的最佳方式是什么？ [关闭]答案

【问题标题】：What is the best way to implement a RESTful architecture in .NET today? [closed]今天在 .NET 中实现 RESTful 架构的最佳方式是什么？ [关闭]
【发布时间】：2011-05-18 02:53:27
【问题描述】：

在你提到它之前，我知道这个问题在 WCF4 推出之前已经被问过，但自 WCF4 发布以来就没有！

因此，经过大量阅读后，我认为 RESTful 架构是开始提供数据的 API 的前进方向。考虑到已发布的 WCF 4、ASP.NET MVC 2 和 WCF REST 入门工具包，现在开始实施 RESTful 架构的最佳方式是什么？

我：我对 ASP.NET MVC 非常熟悉，所以在那里我会感觉很舒服。但是，我缺乏对 WCF 的了解。

那么 WCF4 还是 ASP.NET MVC？（或其他类似 wcf rest starter kit 的东西）？具体来说，我正在寻找：

易于实施
我知道 ASP.NET MVC，而不是 WCF。 WCF 值得学习曲线吗？
WCF4 对 REST 是否过度杀伤，或者 ASP.NET MVC 在某些时候会不足？

【问题讨论】：

没有足够的信息来回答这个问题。已经看答案了。他们没有实质内容，只是“因为我有而使用它”。回答这些问题的唯一方法是将功能与您的确切要求进行比较。因为除了与底层框架无关的“低带宽”和 REST 的定义“许多客户端”之外，您没有提供任何东西，因此几乎不可能给您任何可靠的建议。
@Alex :/ 考虑到他要求“最佳”并引用“WCF 4、ASP.NET MVC 2 和 WCF REST”，对这个问题的奇怪解释
@Alex 谢谢。 @jfar 我试图让它对你更具体。我只是想让有人告诉我，他们是否在任何一条路线上都经历了很长一段时间的战斗，发现它是完美的还是有缺陷的
确实，你为什么要受限于 MS 框架？就 Web 开发和 ReST API 而言，这几乎不是创新所在。

标签： asp.net-mvc wcf rest

【解决方案1】：

我实际上已经实现或正在使用所有已发布的 3 个选项，所以我会给出我的看法。既然您已经阐明了您要寻找的内容，那就更容易回答了。

OData

OData 在以下情况下非常适合内部应用程序：

您既是服务器又是客户端。
您正在使用实体框架。
您没有在模型中使用继承，也不希望查询子集合。

Odata 很棒，因为您可以在客户端使用 IQueryable。不过，这有一些限制。我想到的两个包括你使用继承模型有点尴尬，你can't do nested collections。

还有一个问题是不知道supported LINQ capabilities are是什么。

如果您绝对需要一个服务层并且只希望对它们进行简单的 CRUD 操作，我建议您使用 OData。每个 OData 问题的主要问题都会导致您有时无法绕过的硬墙。客户端消费者代码确实是最好的部分，如果您不使用 C# 来使用它可能不值得。

此外，如果不使用 EF 自动元数据支持，您将编写相同数量的代码以符合您的消费者可能喜欢或不喜欢编写的架构。虽然有一个用于 OData 的 Rails 包装器，但所有这些都是相对较新的。除了真正的大型 MS 合作伙伴之外，我还没有在野外看到 OData。

OData 身份验证和过滤也是非常简单的 ATM。如果您需要限制数据，您将自己编写大量与权限相关的代码。如果您希望 SELECT * FROM TABLE 受权限限制，请准备编写一些笨拙的代码。

MVC 2

MVC 非常适合制作 RESTful 服务。你有动词支持，return JSONResult 就这么简单。唯一潜在的缺点是您自己编写了很多错误处理代码，并且您的所有视图模型都应该从显示状态代码和错误消息的基类继承。

您可能还需要根据您希望消息回复的花哨或约定驱动的方式稍微调整视图引擎。 MVC 的巨大好处是它非常可扩展，你几乎可以做任何你想做的事情。我很喜欢将表单/ajax 调用/和休息服务组合到同一个控制器操作中。实施一次，获得三种风格的相同操作。很难让 MVC 功亏一篑，因为它几乎可以被扭曲来做任何你需要的事情。

MVC 服务的一大好处是，您可以在与服务一起部署的应用程序中隐藏一些管理 UI。无需部署两个站点非常方便。

WCF REST

所以我只在非常有限的容量下使用 WCF 休息，而且似乎...好吧...我已经使用 WCF 3 年了，我总是对扩展它的复杂性感到不满意。就像 ODATA 一样，如果您不走寻常路，您将很快遇到密封类和不可扩展的功能洞穴。这与 MVC 的可扩展性大相径庭。

另一个问题是您在 WCF 之上构建以及随之而来的所有疯狂。我一直说需要博士学位才能有效地使用 WCF。 Rick Strahl 有一篇关于pain points of WCF REST 的好文章。不确定事情是否发生了变化，但值得一读。

WCF REST 看起来很有前途，我现在正在使用它，但我对它的了解还不够，无法推荐。

要点

如果您不了解您的消费者，那么我会假设您不了解您的 API。在你有一个用例并且可以针对它进行编码之前，不要构建一个服务。
MVC 是最具可扩展性的，如果您熟悉事物在幕后的工作原理，您可能会比实现难以扩展的 MS 事物（如 OData 和 WCF）更好。
Facebook、Amazon、PayPal、Ebay 等所有“大男孩”的 API 并不真正符合任何已知模式或架构，如 OData。您的 REST 服务确实是您所创造的。这与#1有关。首先集中精力让消费者更容易与之合作。

【讨论】：

您仅对“要点#1”投了赞成票 :-) 很多人尝试设计一个 API 的想法是他们只是公开数据，而无需了解它将如何使用。
很好的答案，谢谢。回复：#1 网站数据服务都是通过 asp.net mvc 网站编写和交付的。刚刚得到了一个新的要求，“我们需要一个用于 iPhone 应用程序的 api，也许将来还会有其他东西。”我对这个领域知之甚少，所以感谢您的帮助！
+1 jfar - 非常好的总结。我在这个任务中都使用了 wcf (http) 和 mvc。我喜欢 wcf 中如此“简单”的身份验证，而在 mvc 中却有更多的痛苦。如果在处理身份验证的 mvc-rest 实现中解决了这个问题，那么我认为这将是我们所有 restful 服务的首选平台。事实上，我们仍然有目前只有 wcf 才能满足的要求（安全方面）。
@jim 不会只通过 cookie / formsauthentication 处理身份验证，因为它只是基于 HTTP 的吗？
BD - 在我的情况下，我公开了公开（90%）和私有 api 方法的混合，这些方法公开为 xml/json。这是发生的身份验证问题 - 即。没有登录表格。在表格的情况下，这一切都很好。这是需要处理的“静默”请求。我还不是 100% 以通用的方式使用 mvc

【解决方案2】：

您应该查看OpenRasta。它是一个以资源为中心的框架，专为在 .NET 中实现 RESTful 架构而设计，并具有对 HTTP 内容协商和摘要式身份验证等功能的强大支持。

OpenRasta 的方法是，您的 API 应该根据资源（通常会紧密映射到您的 API 实体模型）和编解码器来定义，而不是根据动词（动作）来实现 API，它们提供解耦的序列化/表示这些资源中的 XML、JSON、HTML 或您的 API 需要支持的任何其他内容格式。

它是开源的，完全用 .NET 编写，包括对 IoC 和依赖项注入的内置支持（这就是它在内部连接在一起的方式），并在 MIT 许可下分发。

2.0 版已经稳定了一段时间，并在多个地方用于生产 - 最引人注目的是 Huddle。

在我看来，OpenRasta 对资源的高度关注意味着它比许多“多用途”Web/HTTP 框架（包括 WCF 和 ASP.NET MVC）更接近 Roy Fielding 对 RESTful 架构的最初愿景。

【讨论】：

我的经验是，将资源映射到实体是一个坏主意。我在处理 ViewModel 或 DTO 等资源方面取得了更大的成功。
啊——这就是我所说的“API 实体模型”而不是“域模型”的意思……你说的完全正确，我只是没有很好地解释它。

【解决方案3】：

在做出任何决定之前，请注意 WCF 中的 HTTP/REST 支持正在发生重大变化。见http://wcf.codeplex.com/。会有大量的向后兼容性，但新库是从 HTTP 和 WCF 的角度完全重写的。

另外请注意，OData 虽然对特定的应用程序子集很有用，但并不是通用的 REST 框架。

如果您现在需要 .net，并且您真的想要正确地使用 REST，请查看 OpenRasta。如果您只想做 REST 是因为它具有良好的营销效果，那么 ASP.NET MVC 可能对您来说已经足够好了。如果您只是处于实验阶段，那么我会继续关注新的 WCF 库。

【讨论】：

【解决方案4】：

我使用 Visual Studio 扩展管理器中提供的 WCF Rest 服务应用程序模板取得了很大的成功。如果您希望快速入门，我会去那里。

【讨论】：

【解决方案5】：

如果您的项目构建在 ORM 框架之上，或者您可以将所有数据保存在内存集合中，OData 就是您的选择。如果没有（即您通过存储过程或类似的方式获取数据），请使用 WCF HTTP 服务（又名 WCF REST）

OData 非常有前途，并且在 IQueryable 接口之上具有极大的灵活性。实际上它类似于 RESTful LINQ。但是，除非您在下面有一些 ORM，否则您将不得不自己实现 IQueryable 东西，这几乎就像实现 ORM。此时，您最好使用较低级别的 WCF HTTP 服务，这些服务可为您提供更多控制权，并且您可以按照自己的方式调整资源。客户端库不会那么强大，但不会期望服务实现所有查询运算符。

【讨论】：