作为客户端的SOAP或REST[关闭]

哇,10个小时了,到目前为止还没有回答这个问题。通常,这些类型的问题会在一瞬间跳出来。

不管怎样,这是你问题的一个奇怪的答案。选择应该取决于以下几点:

1. 这两个API的文档有多好。
2. API更改的可能性有多大。
3. 我要多长时间才能给客户
4. 客户可能使用多长时间。
5. 其余的API文档是否包含一个带有返回XML/JSON的URL列表?

无论哪个API有更好的文档,都可能是更好的API。这并不能保证,但它是一个很好的指标。无论SOAP是优于REST,还是相反,如果实现是垃圾的,那么无论哪种方式,您都会受到影响。

如果这是一个由初创公司创建的全新API,它很可能在明年发生重大变化,那么RESTAPI可能更容易管理。由于生成的客户端代理代码,SOAP API往往非常脆弱,需要频繁地重新编译客户端。

尽管我讨厌客户机生成的代理代码有1001个原因,但如果您需要快速得到一些有用的代码的话。将您最喜欢的IDE指向WSDL块将很快获得一个可以使用的对象模型。这绝对是最快的方法,使一些工作。

如果客户要在身边待上几年,那么我认为值得花时间来创造一个好的休息客户。基于休息的方法更能适应随着时间的推移而发生的不可避免的变化。在版本REST客户机方面,还有比基于SOAP的客户机更多的选择。

最后一项是测试RESTAPI是否是真正的REST接口。如果文档是HTTP端点的目录,那么您可以非常确信,设计人员不知道REST是什么,因此请远离它。

你的假设有缺陷。

你说:

如果你要写申请书 在两个网络之间选择 服务API在每个 除了一个是肥皂另一个 休息,你会选择哪一种 为什么?

事实上,SOAP API很可能与REST系统完全不同,所以在这个级别上您不能进行真正的比较。

REST是一种体系结构,而不是协议。SOAP是一种协议,但不是体系结构。虽然可能,但您不太可能在SOAP协议的基础上创建一个REST体系结构,因为SOAP有效负载不会为REST系统提供太多。

SOAP系统往往更基于RPC,而REST系统则基于资源。这两者在操作上和设计上都有显著差异。

就通过HTTP使用SOAP与XML/JSON(许多人错误地将其与REST混淆)而言,SOAP系统的主要好处是可以使用工具使与系统的接口和从系统发布更容易。

今天,许多IDE和服务器可以很容易地发布和使用SOAP Web服务。

在爪哇中,发布一个SOAP接口可以少一些在文件中粘贴“@ WebService”并部署它。使用Web服务只需将IDE指向WSDL(在发布Web服务时方便地为您创建),单击按钮,让工具创建封送数据和与服务通信所需的代理。

基于HTTP的XML/JSON有一个好处,您可能会跳过使SOAP自动化变得“容易”的大部分锅炉盘。当然,javascript非常擅长使用JSON,所以如果您是客户机空间,包括Web浏览器,这可能是一个因素。

归根结底,如果您通过HTTP与浏览器、XML/JSON进行交谈,那么实际的REST体系结构也可以很好地工作。

如果您在服务器之间讨论RPC,那么SOAP就更容易实现了,因为现在有可用的工具。