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

Question

背景
我正在研究当代Web应用程序中消息传递的效率，研究XML替代品的使用。 这是一个大学项目，其结果将公开发布 - 社区的参与越多，所得到的结果的价值就越大。

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

• 完全理解当主机A与主机B通信时使用XML的用途
  我当然可以想象应该如何/可以使用XML。 现实可能完全不同。
  
• 对实际非假设数据进行测试
  与技术X相比，XML在实际数据集上的表现与XML在任意数据集上与技术X的比较同等重要
  
• 识别和测量XML的任何使用模式
  例如，仅元素，元素加上一些属性或最小元素以及繁重的属性用法

问题

你如何的web应用程序的世界中使用XML？

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

理想的答案包括：

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

made, developed or worked on, although any examples are welcome. 我更喜欢制作，开发或使用的应用程序/服务的示例，但欢迎任何示例。 从5行XML文档到10,000行怪物的任何东西都会很棒。

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

更新
我非常感谢关于XML主题的所有答案，但我真正想要的是包含XML的HTTP响应主体的现实例子 。

我目前非常了解XML的历史，可能存在哪些常见替代方案，以及它们如何在特征和适用性方面与特定方案进行比较。

什么会带来更大的好处将是对当前如何在HTTP主机之间的数据交换中使用XML的印象，无论当前使用是否正确或适当。 XML被误用的情况的示例与正确应用XML的情况一样有价值。

Answer 1

我尽量不要使用它。 它绝对有一个架构中的传输协议，客户端和服务器彼此不了解并且是独立实现的 - 或者是独立于任何客户端开发的API。 它在持久性中也有一个适用相同推理的地方，并且我在该域中反对它的次数要少得多。

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

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

HTTP中的XML，即SOAP，打破了这一点。 理由是非常理智，有一个普遍理解的握手协议，一种计算机世界语 ，这样你就可以分离你的客户端和服务器架构，并完全分开决定他们的开发速度和内部。 更重要的是，通过承诺切换客户只是实施新客户的要求，您可以面对未来的客户需求。 更重要的是，允许任何带有XML解析器的Joe使用您的API。 所有伟大的东西，并导致了非常好的标记架构 - 这完全是好的。

所以在相当大程度上这个命题的力量已经显现出来并且显然有优势，但是我认为a）这个要求经常被夸大了; b）XML协议通常非常粗暴地实施，并且很少考虑处理成本意味着。 更原始理智的推理已经让位于极端主义宗教的情况（我打赌我被投票了）我已经看到代码在相同类中的函数调用之间传递XML，正好使用了面向未来的理由和功能分离参数，显然是疯子。

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

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

这就是我认为未来可能存在的地方。 我确信可以保留XML代表的所有上端用于接口的发布，但是能够显着地减少它并减少处理器和带宽 - 至少这是我作为开发人员和架构师的使命。

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

Answer 2

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

Answer 3

我的建议是跳过XML并查看更简单的JSON。 XML只提供两件事：

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

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

如果您传递的数据可以表示为简单的字符串，数组或关联数组（或哈希），则XML过度。

Answer 4

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

Answer 5

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

根据我的经验，xml已经成为我近年来90％以上的后端服务器到服务器通信的标准格式，纯粹是因为使用它的工具很普遍，而且大多数开发人员都有一些经验。

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

如果您向外界销售服务，如果您提供基于xml的界面，CIO会更容易销售，CIO会读取“基于xml的Web服务”，CIO说“很好，我的团队知道......”

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

Answer 6

我不认为XML是一种字节有效的语言，但这不是它的用途。 XML提供的是可以构建协议的良好基础结构。 对于我所使用的产品，我们使用SOAP来发送和接收业务数据到我们无法控制的外部系统，但接受SOAP是一种健全的通用消息传递协议。 类似地，我们使用SAML断言在系统之间交换授权数据。

Answer 7

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

我不认为我可以发布任何例子，但我认为它不会发生太大变化。

Answer 8

我将给出两个使用XML满足的需求示例：

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

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

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

Answer 9

Eucaris是一个用于检索汽车注册数据的Web应用程序。 后端使用XSD类型的XML数据来处理请求和响应消息。

Answer 10

像许多其他人一样，我曾经尝试过使用SOAP和XMLRPC，但发现浏览器支持非常弱，以至于当MSXML在输入上进行barfed时，我需要“回退”在ad-hoc解析器上。 早期版本的netMail应用程序过去常常使用XML，而MSIE对XML解析的速度不够快。 如果你真的有兴趣看到它，我仍然有XML实现。

两个真实的例子映入脑海立即为那些我不得不处理在过去的几个月里：

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

MRIS的XML提要由<Data Separator =“〜”>之类的行组成，然后是一堆~ delimited数据。 这些源很多兆字节，只需采用面向行的读取+拆分而不是“XML”的方法，可以在更少的内存和更快的速度下完成工作。 “XML”数据定期通过HTTP GET下载。

我再也不会使用XML了; 总是ad-hoc解析器。 我认为XML是一个设计决策，是一个令人难以置信的短视的， 最好的天真的证据，以及其他时间的彻头彻尾的愚蠢。

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

对不起，我无法帮助你在网上提供任何好的XML示例; 我根本不认为有任何。