当我没有完全接受REST时，我应该使用Web API吗？

Question

我正在开发一个在桌面浏览器，平板电脑浏览器和手机浏览器中运行的单页应用。我只从后端返回JSON，它是ASP.NET MVC或Web API。

当我想到Web API或阅读它时，我总是听到REST / RESTfull这个词。独立于REST，我喜欢Web API的一些功能，我没有在MVC中（默认情况下，但也许它可以以某种方式实现，但我不想要额外的努力......）

• 创建Ressource时，为GET或201返回类似于200的HttpStatus代码。我的单页应用程序知道并对此代码作出反应。
• 直接在控制器中返回DTO，c＃类自动序列化为json。使用MVC，这不是一个单行。不处理ActionResults。
• Web API非常关注'酷'网址/路由我也会在我的客户端上进行深度/复杂路由。
• 我的Web API端点只是'ajax回调'我不需要REST，比如在每个检索到的资源中包含一个self.link ......

当然，我不会在Get请求中创建/修改资源。但是当我做MVC时，我已经习惯了这种风格。所以我喜欢并且会做很多REST样式，但不是因为REST本身而是常见的做法。

我真的应该设计出很棒的restfull API来使用Web API吗？我不知道微软的Web API的推荐是什么，或者他们真的有关于它的指导...

Answer 1

根据我的经验，Web API通常是一个很好的帮助，而且很少成为障碍。如果你“按他们的方式”这样做，它可以为你节省很多关于序列化/路由/绑定的丑陋工作。如果你不想“以自己的方式”这样做，你就不必这么做了。您可以扩展路由引擎。您可以实现自己的序列化。您可以在您认为合适的地方返回原始JSON。 Web API中没有任何内容强迫您遵循REST概念到T（相信我，我已经看到了这一点）。我之前没有听过任何使用它的人的投诉 - 我建议你试一试，看看它到底有多远。

Answer 2

REST根本不需要使用Web API。实际上，打开并使用会话管理也很容易。

事实上，虽然RESTful方法有一些真正的优势，但我不建议使用100％RESTful。如果不使用第三方身份验证提供程序，则无法使其完全安全。我们构建了一个完全RESTful的原型，并探索了许多不同的机制来保护站点。但最终，每个人​​都有一个或另一个漏洞（它有助于在员工身上拥有CISSP）。所以我和Norton的一位顶级安全专家进行了交谈，他同意，是的，总有一种方法可以开发一个完全RESTful的独立应用程序。赛门铁克显然正在构建一种可以解决这个问题的“包装”技术，但是使用第三方身份验证提供商或者使用会话cookie返回基于MS的安全性更容易。