使用JSON接收和发送数据通过简单的HTTP请求完成。而在SOAP中，我们需要处理很多事情。解析XML有时也很困难。甚至Facebook在Graph API中也使用JSON。我仍然想知道为什么还应该使用SOAP?是否存在SOAP仍然是更好选择的原因或领域?(不考虑数据格式)
同样，在简单的客户机-服务器应用程序中(如与服务器连接的移动应用程序)，SOAP能比JSON提供任何优势吗?
考虑到我提供的信息(如果有的话)，如果有人能列出JSON和SOAP之间的主要/突出区别，我将非常感谢。
我发现SOAP的优点如下:
- 每个人都坚持使用SOAP而不是JSON的一个重要原因。对于每个JSON设置，您总是会为每个项目提出自己的数据结构。我指的不是数据如何编码和传递，而是如何定义数据格式，即数据模型。
- SOAP有一种业界成熟的方式来指定数据将采用某种格式:例如"购物车是产品的集合，每个产品可以具有这些属性，等等"。一个组织良好的WSDL文档确实做到了这一点。参见W3C规范:Web服务描述语言 JSON也有类似的方法来指定这种数据结构——JavaScript类是最常用的方法——但是JavaScript类并不是真正用于这种目的的数据结构，以任何一种不可知的、建立良好的、广泛使用的方式。
简而言之，SOAP有一种在格式化成熟的文档(WSDL)中指定数据结构的方法。JSON没有一个标准的方法来做这件事。
如果你正在创建一个客户端应用程序，而你的服务器实现是用SOAP完成的，那么你必须在客户端使用SOAP。
另外，请参见:为什么在"企业"应用程序中使用SOAP而不是JSON和自定义数据格式?[closed]
现在SOAP完全是一个多余的东西，恕我直言。使用它很好，学习它很好，现在我们可以使用JSON了。
SOAP和REST服务(无论是否使用JSON)之间的唯一区别是SOAP WS总是有自己的WSDL文档，可以很容易地转换为自描述文档，而在REST中，您必须为自己编写文档(至少要记录数据结构)。以下是我对两者的优缺点:
优点
- 轻量级(无论如何:不需要服务器端或客户端扩展，不需要到处传输大块XML)
- 自由选择数据格式-由您决定是否可以使用纯TXT, JSON, XML，甚至创建您自己的数据格式
- 大多数当前的数据格式(即使使用XML)确保只有真正需要的数据量通过HTTP传输，而使用SOAP时，对于5字节的数据，您需要1 kB的XML垃圾(夸张，ofc，但您明白了)
缺点
- 即使有工具可以从docblock注释生成文档，如果想要获得好的文档，也需要以非常描述性的方式编写这些注释
SOAP
优点
- 有一个WSDL，甚至可以从基本的docblock注释(在许多语言中甚至没有它们)生成，它可以很好地作为文档工作
- 甚至有可以与WSDL一起工作的工具来提供增强的尝试这个请求接口(虽然我不知道有任何这样的REST工具)
严格数据结构
缺点
- 严格数据结构
- 使用XML(仅!)进行数据传输，而每个请求包含大量垃圾信息，响应包含五倍以上的垃圾信息
- 对外部库的需求(对于客户端和/或服务器，尽管现在有这样的库已经成为许多语言的本机部分，但人们总是倾向于使用一些第三方库)
总而言之，我看不出有什么理由更喜欢SOAP而不是REST(和JSON)。两者都可以做同样的事情，在几乎所有流行的web编程语言中都有对JSON编码和解码的原生支持，使用JSON你有更多的自由，并且HTTP传输从许多无用的信息垃圾中清除。如果我现在要构建任何API，我会使用REST与JSON
我对JSON的趋势有一点不同意。尽管JSON要简单一个数量级，但我敢说它的局限性很大。例如，SOAP WS并不是最后一件事。实际上，在soap客户机/服务器之间，您现在拥有企业服务总线、基于加密的身份验证方案、用户管理、时间戳请求/应答等。对于所有这些，有一些大型的软件平台围绕SOAP提供服务(好吧，"web服务")，并将东西注入到XML中。因此，尽管JSON对于小项目来说可能已经足够了，而且在小项目中会简单一个数量级，但我认为，如果你将传输控制和内容解耦，它就会变得相当有限。您开发内容和实际的服务器，但所有的传输都由另一个团队管理，身份验证由另一个团队管理，部署由另一个团队管理)。我不知道我在大公司的经历是否与此相关，但我敢说JSON在大公司是无法生存的。除了数据表示的基本需求之外，还有太多的约束。所以问题不是JSON RPC本身，问题是它错过了管理复杂应用程序中出现的复杂性的额外工具(并不是说你所做的不复杂，只是软件反映了生产它的公司的复杂性)
我认为在这个线程上有很多基本的错误信息。SOAP、REST、XML和JSON的概念似乎在响应中混淆了。
这里是一些澄清-
XML和JSON(以及其他)是信息编码。SOAP是一种通信协议REST是一种(架构)风格
每一个都用于不同的内容，尽管您可以同时使用多个
。
让我们从将数据结构编码为XML与JSON开始:
JSON当前支持的一切都可以在XML中完成，但不能反过来。 JSON最终将采用XML所有的特性，但是它的支持者还没有遇到所有的问题，一旦他们有了更多的经验，就会添加一些东西来缩小差距。例如，JSON一开始并没有schema和二进制格式。
SOAP是用于调用操作的通信协议。它运行在HTTP、SMTP等之上。除了许多其他特性之外，SOAP消息还可以跨越多个"应用程序"。层协议。也就是说，我可以通过HTTP将SOAP消息发送到服务端点，然后将其放在另一个系统的消息队列中。当请求在分布式系统的不同部分之间移动时，SOAP解决了维护身份验证、消息真实性等问题。
JSON和其他数据格式可以通过SOAP发送。我使用一些通过SOAP发送二进制固定宽度编码对象的系统，这不是问题。
这个类比是——如果只允许邮递员给你发一封信，那么它就只是HTTP，但是如果任何人都可以给你发一封信，那么你就需要SOAP。(即消息传输安全性与消息内容安全性)6个REST约束是架构风格。有趣的是，在REST的头几年里，示例是在SOAP中。(没有REST或SOAP这样的东西，它们不是对立的)
A"重量级臃肿，等等";SOA SOAP系统可能具有单个实体的GET、PUT、POST实例等操作的单体。SOAP没有预定义这些操作，但这是典型的使用方式。
考虑如果你构建了一个"REST"使用SSL/TLS终止代理，那么您可能违反了REST的第四个约束。
因此，对于今天的软件开发，您通常不会直接与其中任何一个交互。就像你在写一个图形程序一样，你通常不会直接使用HDMI和DisplayPort。
问题是你是否从架构上理解你的系统需要做什么，并配置它来使用完成这项工作的机制。(例如，将今天的微服务应用于一般系统的所有挑战都是以前由SOAP、CORBA和旧协议解决的老问题)
我花了几年时间编写SOAP web服务(使用JAX WS)。它们不难写。我喜欢单一端点和单一HTTP方法(POST)的想法。对我来说，REST太啰嗦了。
但是作为一个数据容器，JSON更简单、更小、更易读、更灵活，看起来更像编程语言。
因此，我重新发明了轮子并创建了自己的方法来编写AJAX请求的后端。相比:
:
- 获取用户:方法获取https://example.com/users/{id}
- 更新用户:方法POST https://example.com/users/(JSON与用户对象在请求体)
RPC :
- 获取用户:方法获取https://example.com/getUser?id=1
- 更新用户:方法POST https://example.com/updateUser (JSON与用户对象在请求体)
My way(建议名称为JOH - JSON over HTTP):
- get user: method POST https://example.com/(JSON指定用户ID和负责处理请求的类/方法)
- update user: method POST https://example.com/(JSON指定负责处理请求的用户对象和类/方法)