对于我们这些不熟企业应用mashup的人来说，门户也许是开始学习的好地方。某些mashup专家，包括我们的朋友Mike Ogrinz，会把门户视为mashup的一种类型，尽管事实上是门户先降生的。应用mashup技术可迅速建立企业门户，但企业应用mashup也能在组织范围内实现许多其他重要目标。据Ogrinz所言，为了让应用mashup发挥作用，REST API能成为其中重要的一部分。

　　按照Ogrinz的说法，数据集成是企业mashup其中的一个主要的用例。“门户的主要目标就是从A处获取不同的数据传递给B”，他说。通过企业应用mashup，开发人员能够回答的其中一个最重要的问题是“我将如何从这个应用中取出或为其获取重要数据”？

　　从某种形式上看，这种观点将企业数据mashup比拟为你也许熟悉的数据析取、转换及加载（ETL）工具。门户或ETL工具与企业mashup的不同也许类似于于各类企业应用与成熟的SOA的不同。在这两种情况下，它们是什么并没有多大的不同，但是它们该如何去搭建却差异很大。

　　通过搭建企业应用及其他基于SOA和Web服务的IT资产，架构师得以建立可容纳增强的集成和可重用的服务的SOA架构。类似地，采用标准服务及应用程序接口（API）使得应用mashup人员快速地对各种不同的IT资产的数据及功能进行混合和匹配。

　　企业应用mashup法则背后的其中一条重要原则是将企业资产（应用及数据源）视为由可能是最基础的构件组成的复合体。上述构件可被视为潜在的应用mashup的原子功能组件。按照Ogrinz的看法，REST是将这些构件浇铸为标准、可重用的造型的最简单的方式。

　　在最近的一次访谈中，Ogrinz告诉我们，在当今的开发人员的技能组合里面，REST属于其普遍拥有的共同特性。SOAP对于.NET的家伙来说可能要简单些，而对于用Java的家伙而言则要困难一点，但这两边的人都会在REST处达成妥协。所达成的这种一致可能跟REST作为Web应用的架构的流行性有关。

　　REST已经改变了许多开发人员解决问题的方式。在过去，你可能会建立一个数据库查询，用来搜索用户数据库，返回给定用户的相应信息。围绕着明确表述的用户需求，你将不得不小心翼翼地做好规划以便确保用户可输入正确的信息进系统中，且系统也将可以返回对用户有用的信息。而现在，Ogrinz告诉我们，生成通用的REST API可以成为搜索相关应用构造和客户化的首选最佳方式。这种方式可降低精确软件需求管理的必要性。

　　随着一批通用API的到位，实时对搜索条件进行重新调整成为可能。不过这的确需要为数据库内的每个关系开发独立的API。因此，包含有用户ID、地址、电子邮件以及公司信息的数据库将会需要为用户ID/地址关系、用户ID/电子邮件关系以及用户ID/公司关系等开发单独的API。

　　一旦其他API就绪，对搜索mashup进行定制来执行数据库任何可能的搜索将成为一个简单的过程。因此，如果需求突然改变了，mashup应用可以马上更新——或甚至用一个新的应用mashup来替换。