由多个源站点无缝合并而成的一个web站点或web应用被称为“mashup”。它带给用户集成体验:分散在各地的页面被以一种新奇的重用模式合并、表达出来。
典型mashup的内容通过公共接口或是API取自第三方来获得。而另一种方式就是通过包含web feeds(比如RSS、Atom)和Javascript(比如google AdSense)来获得内容。
大家会在以下的地方对mashup有所体验:eBay、Amazon、Google、Windows Live和Yahoo开发网络。
二、“物美价廉”的乐高平台
mashup作为一个建立web应用的新方式，它在单一页面中合并了来自多个源站点的程序和数据服务。通称，通过将javascript作为各个源页面之间的“粘合剂”使这些组件和连接被乖巧地布局在同一个页面里，这样并无需昂贵的花费就生产出有价值的“新产品”。
mashup就如一套乐高玩具(比如乐高星战系列)，把现存的有趣东西粘合在一起。
三、互联网上的“裸奔”
这里的裸奔并非在光天化日之下的赤裸行为，而是将自己一丝不挂的充分暴露在互联网中，等待着种种无情的“欺辱”。
下面来看一下可能导致mashup裸奔的原因:
1.束手无措的javascript:在组件包含私有信息或者带有私有连接时mashup就无法工作了(至少整个页面已经被forbidden提示搞得丑陋不堪)。javascript提供了一些穿过这些“封锁”的暗门，但它所依赖的单独的全局对象却由于包含页面和被包含页面之间的互不信任而被禁止。
2.无衣遮身的DOM:mashup中的DOM对安全来讲真是很糟糕，因为每个DOM节点都直接或者间接地链接到另一个节点，这导致不能在有效地隐藏DOM的同时充分地调用其全部功能。
3.相对过激的iframe:<iframe>结构隔离了组件是它们之间不能相互攻击，这中隔离策略对安全很好，但这支双刃剑也刺破了组件之间的“协作”。而mashup是需要组件协作的。
4.能力有限的ajax:采用XMLHttpRequest调用有限的服务——无法访问到被包含页的未开放服务。如果没有通过服务器的代理就无法mash up。
另外，一些富媒体(rich media)广告是mashup的。这些ad脚本需要访问页面的所有信息，包括cookie和到服务器的授权连接。而当前的浏览器设计并没有关照这个集成层次，安全模式仍然遵守着保护本站安全的原则。
所以mashup需要一个更加细粒度的解决方案。
四、安全的驰骋
想要克服mashup的陋习，结束裸奔生活也非难事。完全的内容隔离是不灵活的，而开放的内容访问又是没有安全感的，看来只有进行双方商定的局部通讯才是安全驰骋的“起跑点”。
JSON出于这个观点提出了很好的解决方案。采用JSON的模块技术就能轻松的给你的mashup装上工作时必要的安全服(不仅防止触电哦!)。
JSON的作者提议一种新的HTML tag，采用它分割单一页面为多个模块。
用法如下:
<module id="NAME" href="URL" style="STYLE" />
module的三个属性:
1.id:被脚本用来访问模块节点;
2.href:定义了脚本文件或者HTML文件的url;
3.style:就是该模块的风格定义——设置模块的尺寸和位置。
每个模块有两个节点(外部节点、内部节点)。其中外部节点只暴露给外部的文档，内部节点是模块的windows对象。在这个模块中一边的脚本不能调用另一边的脚本来访问或修改另一边的数据结构和文档结构。只允许在内部、外部的节点之间进行收/发通讯。
外部节点具有发送方法，可以发送一个JSON字符串给内部节点的脚本。
外部节点还具有接收方法，可以接收来自内部节点的JSON字符串。
内部节点也有同样的发送和接收功能。
当调用发送方法时，如果对方的接收方法没有定义，那么抛出一个异常。
这样的通讯只允许通过相互协来发送和接收。而且通讯内容只能为JSON text，JSON text可以承担简单的交换和复杂的数据结构(没有交换javascript对象时发生的容量泄漏)。
和模块内部通讯机制类似，每个模块可与一个页面进行协作，而页面也可以使在模块之间的通讯更为方便。模块与页面之间通讯的能力仅仅依靠协作式发送和接收功能。而模块的来源和页面是不相关的。
五、启示:
JSON作者提供了达到一种全新浏览器安全模式的起点。web应用开发因此可以“领先于”浏览器技术(也许浏览器会很快跟上来)。
而这种模块的作法没有对javascript进行任何修改，而只是对HTML进行微小改动。
六、参考资源:http://www.json.org/module.html
文章来源于领测软件测试网 https://www.ltesting.net/
