我应该使用基于REST的服务通过API连接C＃和Java（或其他技术）吗？

Question

我们正在创建一个适合基于REST架构的优势的API。然而，我奋斗的地方在于从不同的技术中消费是多么容易。

它是一个c＃WCF服务，如果通过c＃消费是一个轻而易举的事，1）给dll提供与调用项目的契约2）在调用url和方法之前使用WebChannelFactory泛型来包装契约。

然而，鉴于这是一个API，我希望其他非基于.net的系统能够与之相互作用。我听到的论点是，开发人员为什么要阅读基于REST的服务的所有文档，手动创建一个http请求（用他们选择的语言），然后解析响应。如果我们使用SOAP创建Web服务，他们只需要添加对它的引用，让他们的coice技术构建用于处理SOAP的调用和响应对象，并使用几行代码进行调用（I在c＃中知道这很容易，显然java也很容易。）

从消费角度来看，从支持SOAP和构建WSDL的引用的不同技术看起来就像SOAP一样。但我真的想使用REST只是有这个论点，我真的不能与它争论。

Answer 1

我还明确建议将SOAP用于此目的。 您已经提到了SOAP对REST的大部分好处。

如果所有事实都指向SOAP，为什么你真的想要创建一个REST服务呢？ 对我来说，REST只具有访问速度更快的优势，但在大多数用例中，并没有那么多，以至于不能利用SOAP的优势。

BTW：如果你创建一个普通的.net WebService，你可以“免费”获得它们，因为它们默认支持SOAP和REST（也许你需要在web.config中启用另一个）。

Answer 2

我只见过一个支持REST的SOAP的论点，我完全赞同，你的问题是：如果客户/客户/用户想要的话，请使用SOAP。如果真的是这个服务的消费者的所有可以更容易地使用SOAP，那么你应该使用它。

当然，如果您想支持没有内置SOAP支持的客户端平台，那可能是另一回事。您不希望您的客户/客户/用户从头开始构建SOAP客户端层，除非您真的不喜欢它们。

Answer 3

反向论证是SOAP仅适用于具有WSDL解析器和SOAP堆栈的平台。如果没有它，那么使用它是完全不切实际的，而REST可以归结为“发送HTTP请求，将结果解析为XML”。

是的，对于支持它的平台上的某些类型的API，SOAP将更容易使用。而在其他情况下，它不是。 :)这真的取决于你想要做什么。

在WCF中，同时启用它们并不是非常困难，因此可能值得这样做并让使用您的API的人选择他们想要使用的内容。

Answer 4

听起来你正在努力的是行业倾向于从基于SOAP的服务转向支持REST，但消费此类服务的工具却滞后。

使用WCF开发服务的一个好处是，您可以从实际应用程序中抽象端点（SOAP，REST等）。因此，排除SOAP或REST似乎为时过早。

一种方法可能是通过定义您希望公开以供消费的声音对象来提供服务。一旦你开发了这个，开始尝试从不同的平台/工具使用服务。您可能会了解到，使用REST服务并不像您想象的那么困难。但是，您可能还会了解到目前您根本不需要REST，但如果需要，您可以选择启用。

Answer 5

根据您的描述，REST是您的最佳选择。

这是需要考虑的事情：

1. 有几个使用SOAP的标准，MS推广WS-I Basic Profile 1.1，它在MS世界之外没有得到广泛的支持，人们很容易遇到连接到您服务的麻烦。

2. 通过利用HTTP（测试，缓存等），REST比SOAP具有许多优势。虽然如果您需要复杂的安全性或消息传递，REST将不支持这种开箱即用的功能。

3. 使用REST服务非常容易，无需任何框架或工具。