在我看来，任何拦截都可以提供即时的麻烦，因为任何人都可以将任何HTML /脚本发送回客户端。
我有兴趣这样做的唯一原因是，每当有一个DOM结构/ CSS更改时，前端开发人员面临巨大的痛苦，所以你现在必须弄清楚你在Javascript HTML构建过程中的位置更新。
你们怎么处理这个？有什么我可以做的事情来减少任何风险或者只是直接的坏主意吗？
在我看来，任何拦截都可以提供即时的麻烦，因为任何人都可以将任何HTML /脚本发送回客户端。
我有兴趣这样做的唯一原因是，每当有一个DOM结构/ CSS更改时，前端开发人员面临巨大的痛苦，所以你现在必须弄清楚你在Javascript HTML构建过程中的位置更新。
你们怎么处理这个？有什么我可以做的事情来减少任何风险或者只是直接的坏主意吗？
我倾向于使用以下规则：
请求并返回HTML以获取快速代码段，然后使用客户端（静态）Javascript插入它们。非常适合提醒信息。
请求并返回大型数据集的JSON。当您想要在客户端进行过滤，分组或排序而不重新请求不同形式的数据时，这非常有用。
请求并返回大型数据集的JSON，但包含JSON记录中每条记录的（转义）HTML片段。这意味着比（2）更多的渲染时间和更多的带宽使用，但可以减少通常复杂的HTML渲染的重复。
请求并返回Javascript，和 eval 客户端。这最适合隐藏，显示，移动和删除等交互。它也适用于插入，但通常类型（1）或（5）更好地工作。
请求并返回Javascript，和 eval 客户端，但在Javascript中包含转义的HTML，因此服务器正在进行HTML呈现。
我最常使用5和1。
我倾向于使用以下规则：
请求并返回HTML以获取快速代码段，然后使用客户端（静态）Javascript插入它们。非常适合提醒信息。
请求并返回大型数据集的JSON。当您想要在客户端进行过滤，分组或排序而不重新请求不同形式的数据时，这非常有用。
请求并返回大型数据集的JSON，但包含JSON记录中每条记录的（转义）HTML片段。这意味着比（2）更多的渲染时间和更多的带宽使用，但可以减少通常复杂的HTML渲染的重复。
请求并返回Javascript，和 eval 客户端。这最适合隐藏，显示，移动和删除等交互。它也适用于插入，但通常类型（1）或（5）更好地工作。
请求并返回Javascript，和 eval 客户端，但在Javascript中包含转义的HTML，因此服务器正在进行HTML呈现。
我最常使用5和1。
在我看来，当有DOM结构或CSS更改时，弄清楚后端服务器中需要更改的位置会更加麻烦。
将所有这些保存在一个地方（HTML文件）可能是将ajax通信限制为JSON的最佳理由。
使用JSON原始html后，您仍然担心内容是安全的，毕竟JSON是JavaScript代码。我想如果您不相信HTML数据的来源，那么您可以接受各种跨站点脚本攻击。考虑将数据作为JSON发送并使用类似Yahoo UI库中的Javascript Templating库，请参阅 http://developer.yahoo.com/yui/docs/YAHOO.lang.html#method_substitute 然后让前端人员维护模板。
我不确定我100％理解这个问题......但......
我们使用GWT并在客户端和服务器之间发送XML。我已经使用GWT代码生成器实现了XML映射系统，因此基于对象本身（使用java类中的Annotations）自动生成XML和JavaScript对象之间的转换代码。
发送直接HTML只会使您的应用程序功能降低，因为它不再能够以任何方式解释数据，而只是用它更新屏幕。这也使现在需要生成HTML的服务器端变得复杂......我会认真避免这种策略。
我有点儿 /task/action/parameter 成语继续在javascript方面。
我的后端严格返回JSON中需要的数据，客户端（js）负责显示它。假设我加载此页面 /#/item/product/5，javascript知道它必须调用“item”对象，方法“product”带有参数5。
这适用于书签链接，所以当有人决定书签时 mysite.com/#/item/product/5 每次加载页面时，它都准确地知道要调用的对象...方法。
我认为在安全性方面没有太大的区别 - 你可以解析不安全的JSON以及不安全的HTML / JS。
它更多地是关于您的应用程序的正确分层 - 如果您直接将HTML注入您的页面，您将必须在业务逻辑级别创建特定于视图的代码，这对我的印象来说不利于清洁且易于交换的层。
我的2美分......
我有兴趣这样做的唯一原因是，每当有一个DOM结构/ CSS更改时，前端开发人员面临巨大的痛苦，所以你现在必须弄清楚你在Javascript HTML构建过程中的位置更新。
你一定做错了。
从AJAX返回的数据应该只是 语义数据，即只有布局改变才会改变的东西。将数据转换为DOM操作最好留给母版页本身定义的Javascript函数。
我把它作为评论，但我正在推动它。
JSON本质上是安全的，问题就是人们用它做的事情。
使用eval来评估它是问题，而不是格式，因为格式是由JSON规范隐式限制的。损坏的JSON会使eval不安全。所以......不要这样做。不要使用eval，请使用专用的JSON解析器。
相同的逻辑可以应用于HTML。将HTML视为“数据”，简单地称为XML，并对其进行处理，而不是盲目地将其标记到您的页面中。
诡计更难以通过这种方式滑倒。