2

我想用“Graceful Degradation”构建网页。也就是说，网页功能甚至禁用了javascript。现在我必须对 AJAX 响应的格式做出设计决定。

如果禁用了 javascript，则对服务器的每个 HTTP 请求都会生成 HTML 作为响应。浏览器使用返回的 HTML 进行刷新。没关系。

如果启用了 javascript，对服务器的每个 AJAX HTTP 请求都将生成……嗯，JSON 或 HTML。

如果是 HTML，则很容易实现。只需使用 javascript 将部分页面替换为返回的 HTML。而且，在服务器端，不需要太多的代码更改。

如果是 JSON，那么我必须再次在 javascript 中实现 JSON-to-html 逻辑，这几乎是服务器端逻辑的重复。复制是邪恶的。我真的不喜欢它。好处是带宽使用比 HTML 更好，带来更好的性能。

那么，优雅退化的最佳解决方案是什么？AJAX 请求返回 JSON 还是 HTML 更好？

4

3 回答 3

3

我认为对于任何特定情况都没有“最佳解决方案”。仅可能是针对特定解决方案的“适当解决方案”。这真的取决于你想要做什么。优雅降级对我来说意味着：

  • 构建一个“足够好”的界面，可以在尽可能多的浏览器（桌面和移动）上运行。
  • 不显眼地添加一些脚本（验证方法、界面元素，如选项卡和滑块等），这些脚本只有在页面加载的浏览器具有使其工作所需的功能时才会出现。

在服务器响应中使用 HTML 还是 JSON 是非常主观的，我经常发现自己很难在它们之间做出选择。有人可能会争辩说，例如，从服务器接收一堆键值对并将它们呈现到现有的选择元素中将意味着更多的代码，因此会花费更多的时间进行编码和更多的潜在错误。相反，您可以简单地从服务器请求预先构建的选择元素，并将其注入容器中。构建元素的逻辑已经存在于服务器上，为什么要用两种不同的语言构建它两次。

另一种观点是 JSON 最大限度地减少了带宽使用，因此值得付出额外的努力来解析一些 JSON 以在客户端上构建一些标记。我发现很容易不同意这种观点，原因有几个（我不是一概而论，不要误会我的意思）。首先，很多很多的网络服务器被配置为压缩/放气/gzip他们的输出，很多很多的浏览器都接受压缩的内容。标记非常可压缩，因为它包含大量冗余（<strong></strong>）。因此有理由认为 JSON 响应的大小不会比带有标记的响应小得多。其次，大型数据集可能意味着客户端上的执行时间相当长（讨厌的嵌套循环很常见 - 在此处弹出的一些问题中很明显）。

我对您的建议是尝试了解每种方法的优缺点，并利用这些信息。您可能想阅读以下内容：

http://www.quirksmode.org/blog/archives/2005/12/the_ajax_respon.html

于 2010-05-01T02:39:01.707 回答
0

IMO，使用 HTML 会带来更大的安全风险（MITM 脚本注入等）。在“重复”上节省的任何时间都应该真正花在附加之前的清理上。

正如您所说，JSON 可以安全地解析并且通常更紧凑，从而节省带宽。

我知道我会选择哪个（JSON）。

于 2010-05-01T01:43:04.893 回答
0

首先，仔细考虑您是否真的需要同时支持启用 JavaScript 的用户和未启用 JavaScript 的用户。在我看来，AJAX 的伟大之处在于它将显示（HTML 的构造）与信息分开。

也就是说，这是一种可能有效的方法：

  1. 编写一个服务器端程序，该程序执行您的页面需要执行的操作，并以最简单的形式返回答案（无论包含什么）。对于简单的输出——比如仅仅表明它是否有效——这可能只是一个数字或一个简单的字符串。对于任何比单个结果更复杂的东西，它可能是 XML。

  2. 编写一个服务器端脚本，简单地调用您的程序并将结果输出为纯文本或 XML。

  3. 编写另一个服务器端脚本，调用您的程序并从中构建一个 HTML 页面。

  4. 在用户调用以运行例程的页面中，包括编写控件（例如按钮）的 javascript，当按下该控件时会发送 AJAX 请求以调用第一个脚本，然后解析结果并相应地更新页面。还包括另一个控件，在 NOSCRIPT 标记中，以便启用 JS 的用户不会看到它，它执行标准表单提交以运行您的第二个脚本。所以你仍然需要两个脚本，但你计算的主要内容只完成一次。

于 2011-09-27T20:43:22.343 回答