我们有许多现有的asmx Web服务，许多客户（如果不是全部客户）都使用这些服务。这些不会很快被重写。
因此，我的简单问题是，创建一个新的web.api层是否有意义，该层在必要时调用现有的Web服务（直到它们被重写），而新方法可以在没有＆＃34; legacy＆＃34;肥皂服务。这最终意味着，在将现有Web服务重新编写/移植到web.api之前，我们将有效地拥有两个接口。
我知道事情通常都是在REST方向上进行，因此对于未来的项目，与web.api进行交互不是一个好方法。斯科特汉塞尔曼此前已经说过，如果有疑问会增加另一层抽象概念，但我不相信他是认真的：）
答案 0 :(得分：1)
这里的问题是基于SOAP的API的方法不太可能映射到REST API的更加资源安排的设计上。
此外，从性能的角度来看，如果您将Web服务外观放在Web服务上，您将会看到非常笨重的东西。
REST越来越受欢迎，但假设一切都朝这个方向发展并不是真的。恕我直言，有时SOAP协议定义的结构化交换可以创建一个非常有用的API。
我当然不会想要包装现有的SOAP接口来创建虚假的REST。