logo标签列表

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

xmlweb-applicationscomparisonmessaging
4

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

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

  • 充分了解A主机与B主机通信时XML的用途
    我可以想象XML应该/可能如何使用。现实可能会有很大不同。
     
  • 对实际数据进行测试，而非假设数据
    XML在真实数据集上的表现与Technology X相比同样重要，而不仅仅是在任意数据集上与Technology X的比较
     
  • 确定和测量XML的任何使用模式
    例如，仅使用元素、元素加一些属性或最小元素和大量属性使用

问题

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

当Host B通过HTTP向Host A返回XML结构化数据时，会返回什么？这可能是服务器在AJAX环境下返回数据，或者是一个服务器从一个或多个其他服务器收集数据。

理想的答案应包括：

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

我更喜欢来自您制作、开发或工作过的应用程序/服务的示例，但任何示例都受欢迎。从5行XML文档到10,000行的大型文件都很好。

您对在示例中使用XML的看法也会很棒（例如，我们实现了XML结构化响应，因为需要X/人员Y，尽管我认为JSON可能更好，因为...；或者，我们使用XML来执行此操作，因为[非常好的原因]，它只是最适合这项工作的选择）。

更新
我非常感谢关于XML的一般性答案，但我真正寻找的是HTTP响应体中包含XML的实际示例。

我目前相当了解XML的历史，以及可能存在的常见替代方法以及它们在功能和适用性方面的比较。

更有益的是了解XML当前在HTTP主机之间交换数据中的使用情况，而不管当前的使用是否正确或适合。XML错误应用的案例与正确应用的案例同样有价值。

10个回答
3
我尽量只在必要时使用它。在客户端和服务器不知道彼此并且独立实现或正在独立开发API的体系结构中，它绝对有其作用作为传输协议。在持久化方面，同样也适用于该原理，并且在该领域我反对它的程度要少得多。
然而，如果客户端和服务器由同一团队实现，则在可读性形式下来回转换几乎没有意义，即使客户端和服务器技术不同，几乎总是有更快、更便宜(以处理为代价)的替代方法。
我在传输协议方面的意见集中在XML出现之前的"糟糕"的客户端/服务器时代，当时带宽和处理能力非常宝贵，架构师的工作就是设计一个协议（通常是二进制的）来实现效率和速度最小化数据包大小。明显的限制是握手非常具体，而且二进制方言无法理解，除非它被发布。好处是它非常高效，并且可以针对手头的应用进行高度优化。很多时候，二进制格式都是公开的（你看过旧版本的Excel BIFF规范吗？这不是一个协议，而是发布二进制格式的一个例子）。
XML在HTTP中，即SOAP，打破了这一点。其基本原理非常明智，使用通用理解的握手协议，一种计算机世界语，以便您可以完全分离客户端和服务器架构，并决定它们的发展和内部。更重要的是，通过承诺只需实现新客户端来将自己未来面对可能的客户需求进行预防。此外，允许任何具有XML解析器的人使用您的API。所有这些都很好，已经导致了非常良好的架构发展-这是完全有利的。
因此，在很大程度上，这个命题的力量已经得到体现，并且显然有优势，但我认为a）这种要求经常被夸大，b）XML协议经常被粗心地实施，并且对它们所涉及的处理成本缺乏考虑。而最初的明智推理已经让位于极端主义宗教的情况（我敢打赌我会被投票否决），我曾看到代码在同一类的函数调用之间传递XML，使用了完全未来面向和功能分离的论点，这显然是荒谬的。
所以我的口号是使通信高效和有效。如果这意味着为任意和未知的使用者提供通用API和协议，那么XML是一个非常好的选择。如果意味着制作闪电般快速、可扩展的客户端/服务器（即Web）架构，那么我会尝试使用二进制协议，通常会自己开发。

JSON的出现证明了XML的一些过于复杂。JSON试图缩短结构元素，同时保持通用性，从而获得更小的数据包的好处。像Adobe的AMF这样的协议通常会更紧凑，几乎完全是二进制的。

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

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

也许不是你想要的答案，但我从不使用XML，它太复杂了（至少对于我的简单需求而言），即使我的需求很复杂，XML也是一个过于复杂的东西，它让我在处理复杂问题时感到害怕。

相反，到目前为止最佳答案。 - Jon Cram
如果XML很复杂，那么什么才是简单的呢？ASN.1+BER？ - bortzmeyer
假设我有四个数据字段，如果它们以XML格式发送，解析代码会是什么样子？？需要复杂的树遍历才能获取几个值。JSON在这方面要好得多。 - hasen
2
我的建议是跳过XML，转而使用更简单的JSON。 XML只提供了两个东西： 1）一种“标准化”的序列化复杂数据的方法 2）通过DTD验证上述序列化的正确性的方法
请注意，“标准化”加了引号。唯一标准化的是格式化标签的方式。标签的含义根本不是标准化的。最终，XML给你的唯一好处就是一个无需自己编写的好解析器。
如果要传递的数据可以表示为简单字符串、数组或关联数组（或哈希），那么XML就过于复杂了。
是的，那涉及到我正在研究的内容。XML 被认为是过度设计。那么，JSON/YAML 这些替代方案在哪些/精确/和/可衡量/的方面更好呢？它们是否提供性能增益？这样的收益如何在业务术语中体现？ - Jon Cram
我同意，但我不会低估拥有一个好的解析器的价值。根据我的经验，大多数人无法编写良好的解析器，它们最终变得非常脆弱。 - user10892
1

我建议你也学习 JSON，它是 XML 的一种替代方案，因为它更加紧凑而被广泛使用。

我正在比较XML和JSON、YAML以及Google Protocol Buffers。目前，我只是试图收集XML的使用数据。 - Jon Cram
我在一款名为Semotus HipLink的产品上工作，我们广泛使用JSON进行AJAX调用。 - fasih.rana
1

很遗憾，由于商业/法律原因，我无法提供任何真实数据。

根据我的经验，在最近几年中，对于90%以上的后端服务器之间的通信，xml一直是标准格式，纯粹是因为有许多工具可用于处理它，并且大多数开发人员都有一些使用经验。

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

如果您正在向外部销售服务，则如果您提供基于xml的接口，则更容易销售。CIO读取“基于xml的Web服务”，CIO说“好的，我的团队知道那个...”

Xml并不总是（有人会争辩从来没有）最好的工具，但是它的普及性以及现有代码库和技能集（好的、坏的和平庸的）使其常常成为候选队列的首选。

1

我认为XML不是一种字节高效的语言，但这也不是它的用途。XML提供了一个良好的基础设施，可以构建协议。在我工作的产品中，我们使用SOAP将业务数据发送到外部系统并接收回应，而我们无法控制这些系统，但接受SOAP是一种可靠、常见的消息传递协议。同样地，我们使用SAML断言在系统之间交换授权数据。

1

我曾多次在Web应用程序中使用XML。每一次都是通过SOAP Web服务来完成的。这是因为我使用Visual Studio编程，它具有出色的内置SOAP Web服务支持。它自动生成OOP包装器，使得从AJAX（客户端）和.NET（服务器端与服务器之间的通信）都可以轻松使用。

我不认为我可以发布任何示例，但我认为这也没有太大变化。

1

我将给你两个使用 XML 满足需求的例子：

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

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

在这两种情况下，我们都需要能够以自我定义的格式传递松散结构化的数据。在这两种情况下，我们发明了一种通用的 XML 结构，它易于由发送过程生成，易于被接收过程存储（基本上是一个长字符串），并且易于被人类阅读和理解，现在和未来都是如此。我们本可以发明除 XML 之外的语法，但当时没有人想出更好的方法，而且它已经为我们服务很好了。我无法分享具体的例子，因为这些数据被认为是专有的。

0

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

0

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

两个真实的例子立即涌入脑海，这些是我在过去几个月中必须处理的例子：

在处理英格拉姆微的XML订购接口时，消息依赖于所有元素的顺序，并且对编码问题非常敏感。没有办法使用标准的XML处理工具与其交互。一个特定的解决方案会更好，因为这样就不会有任何问题，元素的顺序也不会有疑问。交换是通过推送和拉取方法进行的；我们的服务器将数据POST到IM-XML的端点，他们的服务器将数据POST回来。

MRIS的XML数据源包含一行类似<Data Separator="~">的内容，然后是一堆以~为分隔符的数据。这些数据源非常大，采用基于行的读取和拆分方法而不是"XML"可以在更少的内存和更快的速度下完成任务。"XML"数据通过HTTP GET定期下载。

我再也不使用XML了，总是使用临时解析器。我认为XML是一个极其短视的设计决策，最多只能证明天真无知，其他时间则纯粹是愚蠢。

通常情况下，当涉及到浏览器时，我发现我经常使用原始的JavaScript表达式（通常称为JSON）（仅因为eval是"尽可能快"）；否则我使用S表达式。

很抱歉，我无法为您提供任何关于XML的好例子；我简直认为根本没有。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接