4

背景
我正在研究当代 Web 应用程序中消息传递的效率，研究 XML 替代方案的使用。这是一个大学项目，其结果将公开发布——社区的参与度越高，回馈的结果价值就越大。

我需要尽可能多的实际使用中的 XML 示例，以便：

  • 完全理解当主机 A 与主机 B 交谈时使用 XML 的内容
    我当然可以想象应该/可能如何使用 XML。现实可能完全不同。
     
  • 对实际而非假设的数据执行测试
    XML 与技术 X 在现实生活数据集上的比较与 XML 与技术 X 在任意数据集上的比较同等重要
     
  • 识别和测量 XML 的任何使用模式，
     例如仅元素、元素加上一些属性或最少元素和重属性使用

问题

您如何在 Web 应用程序的世界中使用 XML？

当主机 B 通过 HTTP 向主机 A 返回 XML 结构的数据时，会返回什么？这可能是在 AJAX 环境中返回数据的服务器，或者是从一个或多个其他服务器整理数据的服务器。

理想的答案包括：

  • HTTP 响应中 XML 的真实示例
  • 请求上述内容的 URL（如果相关）
  • 如果需要，解释数据代表什么
  • 解释（如果不是很明显）为什么要交换此类消息（例如，为了满足用户请求；主机 X 向主机 Y 返回健康状态报告）

我更喜欢您制作、开发或工作过的应用程序/服务的示例，尽管欢迎任何示例。从 5 行 XML 文档到 10,000 行怪物，任何东西都很棒。

您自己对示例中使用 XML 的看法也很棒（例如，由于需求 X/Person Y，我们实现了 XML 结构的响应，尽管我认为 JSON 会更好，因为 ...；或者，我们使用 XML这样做是因为 [非常好的理由]，而且它只是这项工作的最佳选择）。

更新
我非常感谢关于 XML 主题的所有答案，但是我真正在寻找的是包含 XML 的 HTTP 响应主体的真实示例。

我目前相当了解 XML 的历史，可能存在哪些常见的替代方案，以及它们在功能和适用性方面如何比较给定场景。

更大的好处是了解当前如何在 HTTP 主机之间交换数据时使用 XML，而不管当前的使用是否正确或合适。错误应用 XML 的例子与正确应用 XML 的例子一样有价值。

4

10 回答 10

3

我尽量不使用它。在客户端和服务器彼此不了解并且独立实现的架构中，它作为一种传输协议肯定有它的位置——或者一个 API 正在独立于任何客户端开发。它在持久性中也有一席之地，同样的推理也适用，我在那个领域反对它的次数要少得多。

但是，如果客户端和服务器由同一个团队实现，那么以人类可读的形式在两者之间来回转换几乎没有意义，并且几乎总是有更快、更便宜（在处理方面）的替代方案，即使客户端和服务器技术是不同的。

将我的评论集中在传输协议上，早在 XML 出现在带宽和处理能力非常宝贵的“糟糕”旧客户端/服务器时代之前，架构师的工作就是设计一个协议（通常是二进制），唯一的工作就是数据包大小最小化的效率和速度。明显的限制是握手非常具体，除非发布，否则二进制方言是不可理解的。好处是它非常高效，可以针对手头的应用进行高度优化。经常发布二进制格式（您是否看过旧的 Excel BIFF 规范 - 不是协议，而是发布二进制格式的示例）。

HTTP 中的 XML，即 SOAP，打破了这一点。基本原理非常合理，有一个普遍理解的握手协议，一种计算机世界语，这样你就可以将你的客户端和服务器架构分开，并完全分开决定它们的开发速度和内部结构。更重要的是，通过承诺切换客户端只是实现一个新客户端的问题，您可以应对可能的客户需求，从而保证自己的未来。更重要的是，允许任何拥有 XML 解析器的 Joe 使用您的 API。所有伟大的东西，并导致了非常明确的架构如雨后春笋般涌现——这非常好。

所以在相当大的程度上，这个命题的力量已经得到了体现，并且有明显的优势，但是我认为 a) 这个要求经常被夸大了 b) XML 协议的实现通常非常草率并且很少考虑它们的处理成本意味着。更重要的是，最初理智的推理已经让位于极端主义宗教的案例（我敢打赌我被否决了），我已经看到代码在同一类中的函数调用之间传递 XML ，完全使用面向未来的基本原理和功能分离论点，显然是疯了。

所以我的口头禅是让沟通变得高效和有效。如果这意味着为任意和未知的消费者提供通用的 API 和协议，那么 XML 是一个非常好的选择。如果这意味着制作闪电般的、可扩展的客户端/服务器（即 Web）架构，那么我会尝试使用二进制协议，通常是我自己的。

JSON 的出现证明了 XML 的潮流有太多的层次。JSON试图在保持通用性的同时缩短结构元素，从而获得更小的数据包的好处。像 Adob​​e 的AMF这样的协议通常更紧凑，几乎完全是二进制的。

这就是我认为未来可能所在的地方。我确信将有可能保留 XML 为接口发布所代表的所有优势，但能够大幅削减它并减少处理器和带宽密集型 - 至少这是我作为开发人员和架构师的使命。

想象一下，如果您的平均客户端/服务器请求是大小的 1/10，并且两端都没有文本解析，但您保留了接口的通用性。我不知道有哪个开发者会接受它。

于 2008-12-13T23:59:46.133 回答
2

可能不是您想要的答案，但我从不使用 XML，它太复杂了，（无论如何，对于我的简单需求），但即使我的需求很复杂，XML 也太复杂了，它让我害怕在复杂的问题中使用它。

于 2008-12-13T23:07:48.983 回答
2

我的建议是跳过 XML，看看像 JSON 这样更简单的东西。XML 只提供两件事：

1）序列化复杂数据的“标准化”方法 2）验证（通过 DTD）上述序列化正确性的方法

请注意，“标准化”在引号中。唯一标准化的是格式化标签的方式。标签的含义根本不是标准的。最后，XML 为您提供的唯一东西是您不必自己编写一个好的解析器。

如果您传递的数据可以表示为简单的字符串、数组或关联数组（或散列），那么 XML 就大材小用了。

于 2008-12-13T23:46:56.547 回答
1

我建议您也学习 JSON，它是 XML 的替代品，并且因其紧凑性而被广泛使用。

于 2008-12-13T23:04:04.293 回答
1

不幸的是，出于商业/法律原因，我无法为您提供任何真实数据。

根据我的经验，xml 一直是我近年来从事的 90% 以上后端、服务器到服务器通信的标准格式，这纯粹是因为使用它的工具很流行，而且大多数开发人员都有一些经验。

像谷歌的协议缓冲区这样的东西对于许多任务来说可能更有效，但是大多数具有“企业”经验的程序员已经知道如何使用的格式的便利性和安全性很难提出商业案例。

如果您向外部世界销售服务，那么如果您提供基于 xml 的界面，则销售会容易得多，CIO 阅读“基于 xml 的 Web 服务”，CIO 说“好吧，我的团队知道......”

Xml 并不总是（有些人认为永远不会）是这项工作的最佳工具，但它的无处不在，以及使用它的现有代码库和技能集（好的、坏的和平庸的）的数量，经常把它推到候选人的头上队列。

于 2008-12-13T23:45:02.060 回答
1

我不认为 XML 是一种字节高效的语言，但这不是它的用途。XML 提供的是一个良好的基础设施，可以在其上构建协议。就我所开发的产品而言，我们使用 SOAP 向我们无法控制的外部系统发送和接收业务数据，但接受 SOAP 是一种可靠的通用消息传递协议。同样，我们使用 SAML 断言在系统之间交换授权数据。

于 2008-12-14T00:50:22.940 回答
1

我曾多次在 Web 应用程序中使用 XML。它一直是通过 SOAP Web 服务实现的。这是因为我在 Visual Studio 中编程，它对 SOAP Web 服务有很好的内置支持。它自动生成 OOP 包装器，允许从 AJAX（客户端）和 .NET（用于服务器到服务器通信的服务器端）轻松使用它。

我不认为我可以发布任何示例，但是我认为它无论如何都不会发生太大变化。

于 2008-12-14T00:53:52.310 回答
1

我将举两个例子说明我们使用 XML 满足的需求：

  1. 我们需要传达从许多 UNIX 服务器收集的有关文件分配的数据，将详细信息发送到 Windows 服务器进行分析。详细信息和摘要都通过 Web 应用程序以图形方式显示。

  2. 我们需要将多种格式的表单响应存储在一个存储库中，以供以后搜索和“回放”。表单在 Web 应用程序中生成、存储、搜索和回放。

在这两种情况下，我们都需要能够以自定义格式传输结构松散的数据。在这两种情况下，我们都发明了一种通用的 XML 结构，它易于发送进程生成，接收进程易于存储（本质上是单个长字符串）、搜索和解码，并且易于人类阅读和理解。在我们都走了很久之后。我们本可以发明 XML 以外的语法，但当时没有人能想到更好的方法，而且它对我们很有帮助。我不能分享具体的例子，因为这些数据被认为是专有的。

于 2008-12-14T03:40:45.453 回答
0

Eucaris是一个检索汽车注册数据的网络应用程序。后端将 XSD 类型的 XML 数据用于请求和响应消息。

于 2008-12-13T23:36:48.957 回答
0

与许多其他人一样，我曾经尝试过 SOAP 和 XMLRPC，但发现浏览器支持太弱，以至于当 MSXML 输入错误时，我需要“退回”到专用解析器。我的 netMail 应用程序的早期版本曾经使用 XML，而 MSIE 在 XML 解析方面根本不够快。如果您真的有兴趣看到它，我仍然有 XML 实现。

两个现实世界的例子立刻浮现在脑海中，因为我在过去几个月里不得不处理：

在处理 Ingram-Micro 的 XML 排序接口时，消息依赖于所有元素的顺序，对编码问题非常敏感。根本没有办法使用标准的 XML 处理工具与之交互。一个特别的解决方案会更好，因为这样就不会怀疑元素的顺序是什么。交换是通过推送和拉取方法执行的；我们的服务器将数据发布到 IM-XML 的端点，然后他们的服务器将数据返回。

MRIS 的 XML 提要由 <Data Separator="~"> 之类的一行组成，然后是一堆 -分隔的~数据。提要有好几兆字节，简单地采用面向行的读取+拆分而不是“XML”的方法可以在更少的内存和更快的情况下完成工作。“XML”数据通过 HTTP GET 定期下载。

我不再使用 XML。总是临时解析器。我认为 XML 是一种极其短视的设计决策，充其量是幼稚的证据，其余时间则是彻头彻尾的愚蠢。

大多数情况下，我发现在涉及浏览器时使用原始 javascript 表达式（通常称为 JSON）（仅仅是因为eval“尽可能快”），否则使用 S 表达式。

很抱歉，我无法为您提供网络上任何好的 XML 示例；我根本不认为有任何。

于 2008-12-14T00:42:14.830 回答