第八章.在请求和响应中使用XML.doc

在 本系列的上一篇文章 中，您看到了 Ajax 应用程序如何以 XML 格式化发往服务器的请求。还了解了为什么这在大多数情况下并不是一个好主意。这篇文章主要探讨在大多数情况下确实是 好主意的一种做法：向客户机返回 XML 响应。 我其实并不喜欢写那种主要告诉您什么不应该 做的文章。很多时候，那都会是一篇非常愚蠢的文章。我要在前半篇文章中解释某些东西，然后在后半篇文章中说明使用您刚刚才学会的那种技术是一个多么糟糕的主意。在很大程度上，上一期文章正是这样一种情况（如果您错过了那一期文章，请查看 参考资料 中的链接），那篇文章教您如何将 XML 作为 Ajax 应用程序的请求数据格式使用。 但愿这篇文章能够弥补您花费在学习 XML 请求上的时间。在 Ajax 应用程序中，使用 XML 作为发送数据的格式的理由很少，但使服务器向 客户机回发 XML 的理由很多。因此，您在上一篇文章中学到的关于 XML 的知识最终将在这篇文章中体现出某些价值。 服务器（有时）不能响应太多的请求 在深入钻研从服务器获取 XML 响应的技术之前，您需要理解，为什么说使服务器发送 XML 来响应请求是一个好主意（以及这与客户机发送 XML 请求不同的原因所在）。 客户机以名称/值对发送请求 回忆一下上一篇文章，就会知道，在大多数情况下，客户机不需要使用 XML，因为他们会使用名称/值对发送请求。因此，您可能会发送一个这样的名称：name=jennifer。只需简单地在连续的名称/值对之间添加一个 “与” 符号（），即可将其放在一起，就像这样：name=jenniferjob=president。使用简单的文本和这些名称值对，客户机即可轻松向服务器请求多个值。很少需要用到 XML 提供的额外结构（及其带来的额外开销）。 实际上，需要向服务器发送 XML 的所有理由都差不多可以归入以下两个基本的类别中： 服务器仅 接受 XML 请求。在这类情况下，您别无选择。上一期文章中介绍的基础知识应已使您掌握了发送此类请求所必需的工具。 您正在调用一个仅接受 XML 或 SOAP 请求的远程 API。这实际上就是上一种情况的特例，但值得单独拿出来提一下。如果您希望在一个异步请求中使用来自 Google 或 Amazon 的 API，就会有一些特殊的考虑事项。在下一期的文章中，我将介绍这些考虑事项，还会给出一些向 API 发送此类请求的示例。 服务器无法（以一种标准方式）发送名称/值对 在您发送名称/值对时，Web 浏览器会发送请求，平台会响应该请求，并承载一个服务器程序，配合它将那些名称/值对转换成服务器程序可以轻松处理的数据。实际上，每一种服务器端技术 —— 从 Java? servlet 到 PHP、再到 Perl、Ruby on Rails —— 都允许您调用多种方法来根据名称获取值。因此，获取 name 属性只是小事一桩。 这种情况并不会将我们引向另外一个方向。如果服务器使用字符串 name=jenniferjob=president 应答一个应用程序，客户机没有任何标准化的简便方法来将每个对拆分成名称和值。您必须手动解析所返回的数据。如果服务器返回一个由名称/值对构成的响应，这样的响应的解释难度与使用分号、竖线或其他任何非标准格式化字符相同。 给我一点空间！ 在绝大多数 HTTP 请求中，转义序列 %20 用于表示一个空格，文本 “Live Together, Die Alone” 将以 Live%20Together,%20Die%20Alone 的形式通过 HTTP 发送。 对于您来说，这就意味没有任何简单的方法在响应中使用纯文本、使客户机以一种标准的方法获取并解释响应，至少在响应包含多个值时是如此。假设您的服务器只是要发回数字 42，那么纯文本是很好的选择。但如果服务器要一次性发回电视剧 Lost, Alias 和 Six Degrees 的近期收视率又该怎么办呢？尽管可以选择许多种方法来使用纯文本发送这一响应（清单 1 给出了一些示例），但没有一种是不需客户机进行某些处理的极其简单的方法，也没有一种是标准化的方法。 清单 1. 收视率的服务器响应（不同版本） show=Aliasratings=6.5|show=Lostratings=14.2|show=Six%20Degreesratings=9.1 Alias=6.5Lost=14.2Six%20Degrees=9.1 Alias|6.5|Lost|14.2|Six%20Degrees|9.1 尽管不难找到拆分这些响应字符串的方法，但客户机将不得不根据分号、等号、竖线和与符号解析并拆分这些字符串。这不是编写使其他开发人员能够轻松理解和维护的健壮代码的方法。 进入 XML 意识到没有任何