我正在寻找（可以说）从XmlHttpRequest. 我看到的选项是：
纯 HTML。让请求格式化数据并以可用格式返回。
优点：调用页面易于使用。
缺点：非常死板，卡在固定的布局上。
.xml _ 让请求返回 XML，在调用页面上使用 XSLT 对其进行格式化。
优点：请求的服务很容易被其他来源使用。
缺点：浏览器对 XSLT 的支持是否足够好？
JSON。让请求返回 JSON，使用 javascript 使用它，相应地呈现 HTML。
优点：更容易“OO-ify”发出请求的 javascript。
缺点：可能不像前两个选项那样容易使用。
我还考虑过选择选项一，同时抽象被调用服务中的视图逻辑，以便切换不同的布局将是微不足道的。出于兼容性原因，我个人认为此选项是三个选项中最好的。
在打字的时候，我得到了另一个见解。根据添加到请求的参数，允许所有三种响应格式是个好主意吗？
如果您正在寻找一种适用于大多数可用框架的快速解决方案，我会选择 JSON。它很容易上手和工作。
如果您正在尝试构建要扩展的更大应用程序（就大小而言，或者可能是您自己的用于 3rd 方扩展的 API），我会选择 XML。您也可以编写一个代理来提供 JSON 或 HTML 格式的信息，但是在构建应用程序时将 XML 作为主要来源绝对值得花时间和精力。
就像@John Topley所说：这取决于。
我同意 John Topley - 这取决于应用程序。有一篇关于 quirksmode 的好文章讨论了您可能想要阅读的每种格式的优缺点：http ://www.quirksmode.org/blog/archives/2005/12/the_ajax_respon.html
我认为这取决于您的应用程序将具有的“ajaxyness”级别。如果您的前端是“富客户端”，al'a gmail，我会选择 JSON 解决方案，因为无论如何您都必须解决生成客户端视图的问题。如果您谨慎地使用 ajax，向用户提供简单的消息，不时更新一些字段等，那么我会选择选项 1，因为您的大部分视图逻辑已经在服务器上。
不同的响应格式应该不难产生。
JSON最适合我，我喜欢保留OO，js但不知道如何很好地解析 XML :)
我认为尝试使用 XmlHttpRequest 将是一个巨大的头痛，除非它是你不介意的头痛类型——要正确地做到这一点，你几乎是在重新发明轮子。话又说回来，人们喜欢在业余时间重新发明轮子，只是说，“嘿，我做到了”。不是我...
我会得到一个像原型或 Extjs 这样的框架，它有很多内置的 XML 和 JSON 数据加载函数，而且你会得到更多可预测的结果，因为这些框架有事件处理程序来确保你的 XmlHttpRequest 成功或失败。此外，您还可以获得对所有各种浏览器的支持。