当 JSON 如此简单且易于处理时，为什么要使用 XML(SOAP)？

Why use XML(SOAP) when JSON so simple and easy to handle?

提问by Umair Khan Jadoon

Receiving and sending data with JSON is done with simple HTTP requests. Whereas in SOAP, we need to take care of a lot of things. Parsing XML is also, sometimes, hard. Even Facebook uses JSON in Graph API. I still wonder why one should still use SOAP? Is there any reason or area where SOAP is still a better option? (Despite the data format)

使用 JSON 接收和发送数据是通过简单的 HTTP 请求完成的。而在 SOAP 中，我们需要处理很多事情。有时，解析 XML 也很困难。甚至 Facebook 在 Graph API 中也使用 JSON。我仍然想知道为什么还应该使用 SOAP？有什么理由或领域 SOAP 仍然是更好的选择吗？（尽管数据格式不同）

Also, in simple client-server apps (like Mobile apps connected with a server), can SOAP give any advantage over JSON?

此外，在简单的客户端-服务器应用程序（如与服务器连接的移动应用程序）中，SOAP 能比 JSON 更具优势吗？

I will be very thankful if someone can enlist the major/prominent differences between JSON and SOAP considering the information I have provided(If there are any).

考虑到我提供的信息（如果有的话），如果有人可以列出 JSON 和 SOAP 之间的主要/突出差异，我将非常感激。

采纳答案by Sunil Kumar Sahoo

I found the following on advantages of SOAP

我发现以下关于 SOAP 的优点

• There is one big reason everyone sticks with SOAP instead of using JSON. With every JSON setup, you're always coming up with your own data structure for each project. I don't mean how the data is encoded and passed, but how the data formatted format is defined, the data model.
• SOAP has an industry mature way of specifying that data will be in the form Cart is a collection of Products and each product can have these attributes, etc. A well put together WSDL document really has this nailed. Heck, it's a W3C specification.
• JSON has similar ways of specifying this data structure. A JavaScript class comes to mind as the most common way of doing this. A JavaScript class isn't really a data structure in any kind of agnostic, well established, widely used way. Heck, JavaScript really only executes in one environment, the browser.
• In short, SOAP has a way of specifying the data structure in a maturely formatted document (WSDL). JSON doesn't have a standard way of doing this.

• 每个人都坚持使用 SOAP 而不是使用 JSON 的一个重要原因。对于每个 JSON 设置，您总是会为每个项目提出自己的数据结构。我不是说数据是如何编码和传递的，而是数据格式化格式是如何定义的，数据模型。
• SOAP 有一种行业成熟的方法来指定数据将采用 Cart 是产品的集合的形式，并且每个产品都可以具有这些属性等。一个组合良好的 WSDL 文档确实能解决这个问题。哎呀，这是 W3C 规范。
• JSON 具有指定此数据结构的类似方法。JavaScript 类是最常用的方法。JavaScript 类并不是任何类型的不可知的、完善的、广泛使用的数据结构。哎呀，JavaScript 实际上只在一种环境中执行，即浏览器。
• 简而言之，SOAP 有一种在成熟格式文档 (WSDL) 中指定数据结构的方法。JSON 没有执行此操作的标准方法。

If you are creating a client application and your server implementation is done with SOAP then you have to use SOAP in client side.

如果您正在创建客户端应用程序并且您的服务器实现是使用 SOAP 完成的，那么您必须在客户端使用 SOAP。

Also See hereand here

另请参阅此处和此处

回答by shadyyx

Nowadays SOAP is a complete overkill, IMHO. It was nice to use it, nice to learn it, and it is beautiful we can use JSON now.

恕我直言，如今 SOAP 完全是矫枉过正。很高兴使用它，很高兴学习它，而且我们现在可以使用 JSON 真是太好了。

The only difference between SOAP and REST services (no matter whether using JSON) is that SOAP WS always has it's own WSDLdocument that could be easily transformed into a self-descriptive documentation while within REST you have to write the documentation for yourself (at least to document the data structures). Here are my cons'&'pros for both:

SOAP 和 REST 服务（无论是否使用 JSON）之间的唯一区别是 SOAP WS 始终拥有自己的WSDL文档，可以轻松地将其转换为自描述文档，而在 REST 中，您必须为自己编写文档（至少记录数据结构）。这是我对两者的缺点和优点：

REST

休息

Pros

优点

• lightweight (in all means: no server- nor client-side extensions needed, no big chunks of XML are needed to be transfered here and there)
• free choice of the data format - it's up on you to decide whether you can use plain TXT, JSON, XML, or even create you own format of data
• most of the current data formats (and even if used XML) ensures that only the really required amount of data is transfered over HTTP while with SOAP for 5 bytes of data you need 1 kB of XML junk (exaggerated, ofc, but you got the point)

• 轻量级（总之：不需要服务器端或客户端扩展，不需要在这里和那里传输大块的 XML）
• 自由选择数据格式 - 由您决定是否可以使用纯 TXT、JSON、XML，甚至创建您自己的数据格式
• 大多数当前的数据格式（即使使用了 XML）确保只有真正需要的数据量通过 HTTP 传输，而对于 5 字节数据的 SOAP，你需要 1 kB 的 XML 垃圾（夸张，ofc，但你得到了观点）

Cons

缺点

• even there are tools that could generate the documentation from docblock comments there is need to write such comments in very descriptive way if one wants to achieve a good documentation as well

• 即使有可以从 docblock 注释生成文档的工具，如果想要获得一个好的文档，也需要以非常描述性的方式编写此类注释

SOAP

肥皂

Pros

优点

• has a WSDL that could be generated from even basic docblock comments (in many languages even without them) that works well as a documentation
  • even there are tools that could work with WSDL to give an enhanced try this requestinterface (while I do not know about any such tool for REST)
• strict data structure

• 有一个 WSDL，甚至可以从基本的 docblock 注释（在许多语言中，即使没有它们）生成，可以很好地作为文档
  • 甚至有一些工具可以与 WSDL 一起使用来增强这个请求接口的尝试（虽然我不知道任何这样的 REST 工具）
• 严格的数据结构

Cons

缺点

• strict data structure
• uses an XML (only!) for data transfers while each request contains a lot of junk and the response contains five times more junk of information
• the need for external libraries (for client and/or server, though nowadays there are such libraries already a native part of many languages yet people always tend to use some third-party ones)

• 严格的数据结构
• 使用 XML（仅！）进行数据传输，而每个请求都包含大量垃圾信息，而响应包含五倍的垃圾信息
• 对外部库的需求（对于客户端和/或服务器，虽然现在这些库已经是许多语言的本机部分，但人们总是倾向于使用一些第三方库）

To conclude, I do not see a big reason to prefer SOAP over REST(and JSON). Both can do the same, there is a native support for JSON encoding and decoding in almost every popular webprogramming language and with JSON you have more freedom and the HTTP transfers are cleansed from lot of useless information junk. If I were to build any API now I would use REST with JSON.

总而言之，我认为 SOAP 比 REST（和 JSON）更受欢迎。两者都可以做同样的事情，几乎所有流行的Web编程语言都有对 JSON 编码和解码的原生支持，使用 JSON，您有更多的自由，并且 HTTP 传输从大量无用的信息垃圾中清除。如果我现在要构建任何 API，我会使用 REST 和 JSON。

回答by wiz21

I disagree a bit on the trend of JSON I see here. Although JSON is an order maginitude easier, I'd venture to say it's quite limited. For example, SOAP WS is not the last thing. Indeed, between soap client/server you now have enterprise services bus, authentification scheme based on crypto, user management, timestamping requests/replies, etc. For all of this, there're some huge software platforms that provide services around SOAP (well, "web services") and will inject stuff in your XML. So although JSON is probably enough for small projects and an order of magnitude easier there, I think it becomes quite limited if you have decoupled transmission control and content (ie. you develop the content stuff, the actual server, but all the transmission is managed by another team, the authentification by one more team, deployment by yet another team). I don't know if my experience at a big corp is relevant, but I'd say that JSON won't survive there. There are too many constraints on top of the basic need of data representation. So the problem is not JSON RPC itself, the problem is it misses the additional tools to manage the complexity that arises in complex applications (not to say that what you do is not complex, it's just that the software reflects the complexity of the company that produces it)

我在这里看到的 JSON 趋势有点不同意。虽然 JSON 是一个更容易的订单量级，但我敢说它非常有限。例如，SOAP WS 并不是最后一件事。事实上，在soap客户端/服务器之间，您现在拥有企业服务总线、基于加密的身份验证方案、用户管理、时间戳请求/回复等。对于所有这些，有一些巨大的软件平台提供围绕SOAP的服务（嗯， “网络服务”）并将在您的 XML 中注入内容。因此，尽管 JSON 对于小型项目来说可能就足够了，并且在那里更容易一些，但我认为如果您将传输控制和内容分离（即，您开发内容，实际服务器，但所有传输都受到管理），它会变得非常有限由另一个团队，由另一个团队认证，由另一个团队部署）。我不知道我在大公司的经历是否相关，但我想说 JSON 不会在那里生存。除了数据表示的基本需求之外，还有太多的限制。所以问题不在于 JSON RPC 本身，问题在于它错过了管理复杂应用程序中出现的复杂性的额外工具（不是说你做的事情不复杂，只是软件反映了公司的复杂性）产生它）

回答by AntiCZ

I am a PHP/JS developer. Reason for JSON is simple. JSON == JS Object.

我是一名 PHP/JS 开发人员。JSON 的原因很简单。JSON == JS 对象。

SOAP is good but is heavy. Question is. It is worth it? Sometimes yes. Sometimes no. And in most cases, you need JSON at the end anyway.

肥皂很好，但很重。问题是。这是值得的？有时是的。有时没有。并且在大多数情况下，无论如何您最终都需要 JSON。

Corps use SOAP because they exchange data with thousands of other entities and they need integrity of data. I think for small or middle projects SOAP is too heavy.

兵团使用 SOAP 是因为他们与数以千计的其他实体交换数据，并且他们需要数据的完整性。我认为对于中小型项目来说 SOAP 太重了。