*您*如何在 Web 应用程序领域中使用 XML？
背景
我正在研究当代 Web 应用程序中消息传递的效率，研究 XML 替代方案的使用。 这是一个大学项目，其结果将被公开发布——社区的参与程度越高，回馈的结果的价值就越大。
我需要尽可能多的实际使用中的 XML 示例，以便：
- 充分理解主机 A 与主机 B 对话时使用 XML 的内容
我当然可以想象 XML 应该/可以如何使用。 现实可能完全不同。
- 对实际而非假设的数据进行测试
在现实数据集上，XML 与 X 技术的性能对比与在任意数据集上 XML 与 X 技术的性能对比同等重要em> 数据集
- 识别和测量 XML 使用的任何模式
例如仅元素、元素加上一些属性或最少元素和大量属性使用
问题
如何 您在 Web 应用程序领域中使用 XML 吗？
当主机 B 通过 HTTP 将 XML 结构的数据返回给主机 A 时，会返回什么？ 这可能是一台在 AJAX 环境中返回数据的服务器，或者是一台整理来自一台或多台其他服务器的数据的服务器。
理想的答案包括：
- HTTP 响应中 XML 的真实示例
- 请求上述内容的相关 URL
- 数据代表什么的解释（如果需要）
- 解释（如果不明显）为什么要发送此类消息交换（例如，为了满足用户请求；主机 X 返回健康状态报告给主机 Y）
我更喜欢来自您制作、开发或工作的应用程序/服务的示例，尽管任何示例受欢迎的。 从 5 行 XML 文档到 10,000 行的庞然大物，任何内容都很棒。
您自己对在示例中使用 XML 的看法也很棒（例如，由于需求 X/人 Y，我们实现了 XML 结构的响应，尽管我认为 JSON 会更好，因为……；或者，我们使用 XML 来这样做是因为[非常好的理由]而且这是这项工作的最佳选择）。
更新
我非常感谢关于 XML 主题的所有答案，但是我真正寻找的是包含 XML 的 HTTP 响应主体的现实示例。
我目前相当了解 XML 的历史、可能存在哪些常见替代方案以及它们在功能和对给定场景的适用性方面如何进行比较。
更大的好处是了解 XML 当前如何用于 HTTP 主机之间的数据交换，无论当前的用法是否正确或合适。 错误应用 XML 的案例与正确应用 XML 的案例同样有价值。
Background
I'm researching the efficiency of messaging within contemporary web applications, examining the use of alternatives to XML. This is a university project whose results will be released publicly - the greater the participation of the community, the greater the value of the results that are given back.
I need as many real-life examples of XML in use as possible so as to:
- fully understand to what uses XML is put when host A talks to host B
I can certainly imagine how XML should/may be used. The reality may be quite different.
- perform tests on actual not hypothetical data
How XML performs compared to Technology X on sets of real-life data is of equal importance to how XML compares to Technology X on an arbitrary set of data
- identify and measure any patterns of use of XML
e.g. elements-only, elements plus some attributes or minimal elements and heavy attribute usage
The Question
How do you use XML within the world of web applications?
When Host B returns XML-structured data to Host A over HTTP, what comes back? This may be a server returning data in an AJAX environment or one server collating data from one or more other servers.
Ideal answers would include:
- A real-life example of XML within an HTTP response
- The URL, where relevant, to request the above
- An explanation, if needed, of what the data represents
- An explanation, if not obvious, of why such messages are being exchanged (e.g. to fulfil a user request; host X returning a health status report to host Y)
I'd prefer examples from applications/services that you've made, developed or worked on, although any examples are welcome. Anything from a 5-line XML document to a 10,000 line monster would be great.
Your own opinions on the use of XML in your example would also be wonderful (e.g. we implemented XML-structured responses because of Requirement X/Person Y even though I thought JSON would have been better because ...; or, we use XML to do this because [really good reason] and it's just the best choice for the job).
Update
I very much appreciate all answers on the topic of XML in general, however what I'm really looking for is real-life examples of HTTP response bodies containing XML.
I'm currently fairly aware of the history of XML, of what common alternatives may exist and how they may compare in features and suitability to given scenarios.
What would be of greater benefit would be a impression of how XML is currently used in the exchange of data between HTTP hosts regardless of whether any current usage is correct or suitable. Examples of cases where XML is misapplied are just as valuable as cases where XML is correctly-applied.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
我将向您提供两个我们使用 XML 满足需求的示例：
我们需要传达从许多 UNIX 服务器收集的有关文件分配的数据，并将详细信息发送到 Windows 服务器进行分析。 详细信息和摘要均通过 Web 应用程序以图形方式显示。
我们需要将多种格式的表单响应存储在单个存储库中，以便以后搜索和“回放”。 表单在 Web 应用程序中生成、存储、搜索和回放。
在这两种情况下，我们都需要能够以自定义格式传送松散结构的数据。 在这两种情况下，我们发明了一种通用的 XML 结构，该结构易于发送过程生成，易于接收过程存储（本质上是单个长字符串）、搜索和解码，并且易于人类阅读和理解，现在两者都在我们都走了很久之后。 我们本可以发明 XML 以外的语法，但当时没有人能想到更好的语法，而且它对我们很有帮助。 我无法分享具体示例，因为这些数据被认为是专有的。
I'll give you two examples of needs that we satisfied using XML:
We needed to communicate data collected from many UNIX servers about file allocations, sending the details to a Windows server for analysis. Both the detail and summaries are graphically displayed through a web application.
We needed to store multiple formats of form responses in a single repository for later searching and "playback". The forms are generated, stored, searched and played back within a web application.
In both cases we needed the ability to convey loosely-structured data in a self-defining format. In both cases we invented a generic XML structure that was easy for the sending process to generate, easy for the receiving process to both store (essentially a single long string), search and decode, and was easily read and understood by humans, both now and after we're all long gone. We could have invented a syntax other than XML, but nobody could think of anything better at the time, and it has served us well. I can't share specific examples because the data is considered proprietary.
我曾多次在 Web 应用程序中使用 XML。 一直以来，它都是通过 SOAP Web 服务进行的。 这是因为我在 Visual Studio 中编程，它对 SOAP Web 服务有很好的内置支持。 它自动生成 OOP 包装器，允许从 AJAX（客户端）和 .NET（用于服务器到服务器通信的服务器端）轻松使用它。
我不认为我可以发布任何例子，但我认为它无论如何都不会改变太多。
I have used XML in web applications several times. All of the time it has been through SOAP web services. This is because I program in Visual Studio which has great built-in support for SOAP Web Services. It automatically generates OOP wrappers that allows easy use of it both from AJAX (client end), and .NET (server end for server-to-server communications).
I don't think that I can post any examples, but then I don't think it changes much anyway.
我尽量不过度使用它。 作为一种传输协议，它在客户端和服务器彼此不了解且独立实现的架构中肯定占有一席之地，或者 API 的开发独立于任何客户端。 它在持久性中也占有一席之地，同样的推理也适用，而且在该领域我对它的反对要少得多。
然而，如果客户端和服务器是由同一个团队实现的，那么以人类可读的形式在两者之间来回转换就没有什么意义，并且几乎总是有更快、更便宜（在处理方面）的替代方案，即使客户端和服务器技术不同。
我的评论主要集中在传输协议上，早在 XML 出现之前，带宽和处理能力都非常宝贵的“糟糕”的旧客户端/服务器时代，架构师的工作就是设计一个协议（通常是二进制的），其唯一的工作是数据包大小最小化的效率和速度。 明显的限制是握手非常具体，并且二进制方言除非发布否则难以理解。 优点是它非常高效，并且可以针对当前的应用程序进行高度优化。 二进制格式经常被发布（您是否见过旧的 Excel BIFF 规范 - 不是协议，而是发布二进制格式的示例）。
HTTP 中的 XML（即 SOAP）打破了这一点。 基本原理非常理智，有一个普遍理解的握手协议，一种计算机世界语 ，这样您就可以将客户端和服务器架构分开，并完全分别决定它们的开发速度和内部结构。 更重要的是，您可以保证自己能够适应未来可能的客户需求，并承诺切换客户只需实施一个新客户即可。 此外，允许任何拥有 XML 解析器的人使用您的 API。 所有伟大的东西都导致了标记清晰的建筑如雨后春笋般涌现——这完全是好事。
因此，在很大程度上，这个主张的力量已经得到体现，并且有明显的优势，但是我认为 a) 这个要求经常被夸大了，b) XML 协议的实现常常非常草率，并且很少考虑它们的处理成本。意味着。 更重要的是，最初理智的推理已经让位于极端宗教的案例（我打赌我被否决了），并且我已经看到代码在同一类内的函数调用之间传递 XML，完全使用面向未来的方法基本原理和功能分离的争论，这显然是疯狂的。
所以我的座右铭是让沟通高效、有效。 如果这意味着为任意和未知的消费者提供通用的 API 和协议，那么 XML 是一个非常好的选择。 如果这意味着打造闪电般的热门、可扩展的客户端/服务器（即 Web）架构，那么我会尝试使用二进制协议，通常是我自己的协议。
JSON 的出现证明了 XML 潮流的层数太多了。 JSON 是一种在保持通用性的同时缩短结构元素的尝试，从而获得更小的数据包的好处。 像 Adobe 的 AMF 这样的协议通常很多更紧凑，几乎完全是二进制的。
我认为这就是未来可能所在的地方。 我确信可以保留 XML 所代表的接口发布的所有优点，但能够大幅削减它并减少处理器和带宽的占用 - 至少这是我作为开发人员和架构师的使命。
想象一下，如果您的平均客户端/服务器请求大小是 1/10，并且两端都没有文本解析，但您保留了接口的通用性。 我不知道有哪个开发商会拒绝这一点。
I try not to use it more than I have to. It definitely has its place as a transmission protocol in an architecture where the client and the server do not know about each other and are implemented independently - or an API is being developed independently of any clients. It also has a place in persistence where the same reasoning applies, and I object to it far less in that domain.
However, if the client and server are implemented by the same team then it makes little sense to translate back and forth between the two in a human readable form and there is almost always a faster, cheaper (in terms of processing) alternative, even if the client and server technologies are different.
Concentrating my remarks on transmission protocols, back before XML arrived in the "bad" old client/server days when bandwidth and processing power were precious, it would be the job of the architects to design a protocol (normally binary) with the sole job of efficiency and speed where packet size would be minimized. The obvious limitation is that the handshake was very specific and the binary dialect was unintelligible unless it was published. The up-side was that it was extremely efficient and could be highly optimised for the application at hand. Very often the binary formats were published (have you seen the old Excel BIFF specification - not a protocol, but an example of publishing a binary format).
XML in HTTP, i.e. SOAP, broke that. The rationale was very sane, have a universally understood protocol for the handshake, a sort of computer Esperanto, so that you could separate your client and server architectures and decide on their pace of development and internals completely separately. What's more, future-proof yourself against possible client requirements with the promise that switching clients was just a matter of implementing a new one. What's more, allow any Joe with an XML parser to consume your API. All great stuff and has led to a mushrooming of very well demarked architectures - which is wholly good.
So to quite a large degree the power of this proposition has been manifested and there are clearly advantages, however I think that a) this requirement is often overstated and b) XML protocols are often implemented very sloppily and with scant regard for the processing cost they imply. What's more the originally sane reasoning has given way to cases of extremist religion (I bet I get voted down) and I have seen code passing XML between function calls within the same classes, using exactly the future-proofing rationale and functional separation arguments, which is clearly bonkers.
So my mantra is to make the communication efficient and effective. If that means providing a generalised API and protocol for arbitrary and unknown consumers, then XML is a very good choice. If it means making lightning hot, scalable client/server (i.e. Web) architectures then I try and use a binary protocol, often rolling my own.
The emergence of JSON is testimony to the fact that the XML bandwagon had a few too many layers. JSON is an attempt to shorten the structural elements while maintaining the generality and thereby get the benefits of smaller packets. Protocols like Adobe's AMF are generally much more compact, being almost entirely binary.
And that's where I think the future probably lies. I am certain that it will be possible to keep all of the up-sides that XML represents for publication of interfaces, but be able to trim it dramatically and make it less processor and bandwidth intensive - at least that's my mission as developer and architect.
Imagine if your average client/server request was 1/10th of the size and there was no text parsing at either end, but you retained the generality of the interface. I don't know any developer who wouldn't take that.
可能不是您想要的答案，但我从不使用 XML，它太复杂了（无论如何对于我的简单需求），但即使我的需求很复杂，XML 也太复杂了，它让我害怕在复杂的问题中使用它。
Probably not the answer you want, but I never use XML, it's too complicated, (for my simple needs anyway), but even if my needs were complicated, XML is too complicated a beast it scares me to use it in a complicated problem.
我的建议是跳过 XML，看一些更简单的东西，比如 JSON。 XML 只提供两件事：
1) 序列化复杂数据的“标准化”方式
2）验证（通过DTD）上述序列化通知的正确性的方法
，“标准化”在引号中。 唯一标准化的是标签的格式化方式。 标签的含义根本不标准。 最后，XML 为您提供的唯一东西是一个好的解析器，您不必自己编写。
如果您传递的数据可以表示为简单的字符串、数组或关联数组（或散列），那么 XML 就显得大材小用了。
My advice is to skip XML and look at something simpler like JSON. XML provides only two things:
1) a "standardized" way to serialize complex data
2) a way to verify (via DTD) the correctness of the above serialization
notice that "standardized" is in quotes. The only thing standardized is the way of formatting the tags. What the tags mean is not standard at all. In the end, the only thing XML gives you is a good parser that you don't have to write yourself.
If the data you're passing around can be represented as a simple string, array, or associative array ( or hash), XML is overkill.
我建议您还学习 JSON，它是 XML 的替代品，并且因其紧凑性而被广泛使用。
I suggest you also study JSON which is an alternative to XML and is widely used for its compactness.
不幸的是，出于商业/法律原因，我无法向您提供任何真实数据。
根据我的经验，XML 已成为我近年来从事的 90% 以上的后端、服务器到服务器通信的标准格式，这纯粹是因为使用它的工具很流行，而且大多数开发人员都拥有一些经验。
像谷歌的协议缓冲区之类的东西对于许多任务来说可能更有效，但是大多数具有“企业”经验的程序员已经知道如何使用这种格式的便利性和安全性很难提出商业理由。
如果您要向外界销售服务，那么如果您提供基于 xml 的界面，那么销售就会容易得多，CIO 会读到“基于 xml 的 Web 服务”，CIO 会说“好吧，我的团队知道......”
Xml 并不总是 如此（有些人认为永远不会）是这项工作的最佳工具，但它的普遍性，以及使用它的现有代码库和技能集（好的、坏的和平庸的）的数量，常常将它推到候选队列的前面。
Unfortunately, I can't give you any real data for business/legal reasons.
In my experience, xml has been the standard format for 90+% of back end, server to server communications that I have worked on in recent years, purely because of the prevalence of tools for working with it, and the fact that most developers have some experience with it.
Something like google's protocol buffers may well be more efficient for many tasks, but the convenience and safety of a format that most programmers with "enterprisey" experience already know how to use is hard to make a business case against.
If you are selling a service to the outside world, it's much easier to sell if you offer an xml based interface, CIO reads "xml based web service", CIO says "fine, my team knows that..."
Xml is not always (some would argue never) the best tool for the job, but its ubiquity, and the amount of existing codebase and skillsets (good, bad and mediocre) for working with it, often push it to the head of the candidate queue.
我不认为 XML 是一种字节效率语言，但这不是它的用途。 XML 提供的是一个可以在其上构建协议的良好基础设施。 就我所开发的产品而言，我们使用 SOAP 向我们无法控制的外部系统发送和接收业务数据，但我们承认 SOAP 是一种健全的通用消息传递协议。 同样，我们使用 SAML 断言在系统之间交换授权数据。
I don't think XML is a byte-efficient language, but that's not what it's for. What XML provides is a good infrastructure on to which protocols can be built. In the case of the product I work on, we use SOAP to send to and receive from business data to external systems over which we have no control, but accept that SOAP is a sound, common messaging protocol. Similarly we use SAML assertions to exchange authorization data between systems.
与许多其他人一样，我曾经尝试过 SOAP 和 XMLRPC，但发现浏览器支持非常薄弱，以至于当 MSXML 在输入时出现问题时，我需要“退回”临时解析器。 我的 netMail 应用程序 的早期版本过去使用 XML，而 MSIE 的速度不够快XML 解析。 如果您确实有兴趣查看的话，我仍然有 XML 实现。
我在过去几个月中不得不处理两个现实世界的例子立即：
在处理 Ingram-Micro 的 XML 排序接口时，消息依赖于的顺序>all 元素，并且对编码问题非常敏感。 根本无法使用标准 XML 处理工具与其交互。 临时解决方案会更好，因为这样就不会存在元素按什么顺序出现的问题。交换通过推式和拉式方法执行； 我们的服务器将数据发布到 IM-XML 的端点，而他们的服务器将数据发布回来。
MRIS 的 XML 提要由类似的行组成。 然后是一堆
~分隔的数据。 提要有很多兆字节大，只需采用面向行的读取+拆分而不是“XML”的方法即可以更少的内存和更快的速度完成工作。 “XML”数据通过 HTTP GET 定期下载。我再也不用XML了； 始终是临时解析器。 我认为 XML 作为一种设计决策是非常短视的，并且在最好的情况下也是天真的证据，而在其他时候则是彻头彻尾的愚蠢。
大多数情况下，我发现当涉及浏览器时我使用原始 JavaScript 表达式（通常称为 JSON）（仅仅因为
eval是“尽可能快”），否则使用 S 表达式。很抱歉，我无法为您提供网络上任何好的 XML 示例； 我认为根本不存在。
Like many others, at one point, I experimented with SOAP and XMLRPC, but found browser-support so weak that I needed to "fall back" on an ad-hoc parser when MSXML barfed on input. Early versions of my netMail application used to use XML, and MSIE simply wasn't fast enough with the XML parsing. I still have the XML implementation if you're really interested in seeing it.
Two real world examples spring to mind immediately as ones I've had to deal with in the last few months:
In dealing with Ingram-Micro's XML ordering interface, the messages are dependent on the order of all elements, and is very sensitive to encoding problems. There was simply no way to use standard XML-processing tools to interact with it. An ad-hoc solution would've been better because then there would be no question what order the elements came in. The exchanges are performed by both push and pull methods; with our server POSTing data to IM-XML's endpoint, and their server POSTing data back.
MRIS's XML feeds consist of a line like <Data Separator="~"> and then a bunch of
~-delimited data. The feeds are many megabytes big, and simply taking the approach of line-oriented reads+split instead of "XML" gets the job done in less memory and faster. The "XML" data is downloaded via HTTP GET periodically.I never use XML anymore; always ad-hoc parsers. I view XML as a design-decision to be an incredibly shortsighted one, and evidence of naivete at best, and downright stupidity the rest of the time.
Most often, I find I use raw javascript expressions (often called JSON) when a browser is involved (simply because
evalis "as fast as possible") and S-expressions otherwise.I'm sorry I can't help you with any good XML examples on the web; I simply don't think there are any.
Eucaris 是一个用于检索汽车注册数据的 Web 应用程序。 后端使用 XSD 类型的 XML 数据来表示请求和响应消息。
Eucaris is a web application to retrieve car registration data. The backend uses XSD-typed XML data for request and response messages.