当我可以创建基于web的RESTful端点时，为什么我应该将OWIN用于基于服务的API呢？

Question

我正在重写现有应用程序的体系结构，该应用程序将托管在Azure上，至少有两个API--一个是公共API，另一个是内部RESTful相关CRUD调用的私有API。

主要技术栈为ODATA、WebAPI2、C#、MVC5、EF、AngularJS。我的想法是，RESTful端点都将通过Azure角色公开(就像任何其他URL一样)。

在阅读更多关于在WebAPI和Azure Worker角色中使用的文章时，它似乎是完全一样的，但是作为一种服务。

走这个自己的RESTful路径有什么好处(想想看，我甚至可以写一个WCF服务来做同样的事情)，而不是基于web的WCF API调用？

我正在寻找一些理由，为什么我应该进行迁移到基于服务的API的练习。

Answer 1

技术讲

对于您的公共API，我建议使用RESTful方式使用Owin。这将为您的内部系统创建一个外观。

在内部，WCF将提供更好的表现。

专业人士

• 如果有一个好的计划，维护就容易多了。由于它的分散设计，重构所带来的风险包含在特定的上下文中。维护就是最小化和控制与变更相关的风险。

这些链接更多地涉及SOA，但我相信您可以从它们中提取所需的信息：

• 按合同提供的服务
• Amazon
• 亚马逊股东信

CONS

但是，您应该知道，因为它也有缺点。您将需要可靠的单元测试、日志记录和版本控制策略。

希望这能帮点忙。我尽量只保留要点，因为这个问题的完整答案可以作为一本书出版。