跟所有的企业数据一样，大数据唯有通过应用投射给用户才有用。对于设计或重新设计大数据应用的架构师来说，一个关键问题是究竟是用面向对象架构(SOA)还是RESTful API将大数据组件及服务与应用其他部分连接。从大数据产品要暴露的接口开始，然后在应用这一侧定义大数据接口。接下来，考虑安全和治理，最后，无论选择什么样的API都要小心地将管理和访问服务分隔开来。
做大数据应用的一个主要问题是与大数据容器本身进行交换的本质。这一关系包括了传统的哪一种抽象级别最适合应用的问题，所需的事务及状态控制以及必要的安全性。
大数据工具往往混合了API,部分RESTful以及部分类似SOA式的API.这种混编会导致一种混乱的景象，除非大数据接口被抽象为服务或资源，而不是直接暴露给应用。这样的话，只有一个组件需要做出变化-大数据适配器流程-如果大数据工具彻底改变了的话。
大数据应用，什么时候用SOA,什么时候用REST
在大数据适配器与其他组件之间的接口处，看看大数据是如何被用来为选择API进行指导的。SOA适合在向大数据容器这样的东西发布一组与应用绑定的特定能力的情况。这一模型可以是高度抽象的，意味着应用使用大数据可以与数据本身的技术和可分布性完全隔绝。
应用预期会在特定分析或规约流程的结果方面更多使用大数据，在这种情况下SOA是有意义的。如果应用需要知道作为资源集的大数据的情况，又不想把它抽象化为高层服务，那么RESTful接口也许会更合适。
在这种高度上进行应用审查，至关重要的一点是不要掉进这样一个陷阱，即假定大数据应用应该用Apache的WebHDFS这类现有的RESTful API来开发。通常而言，最好的办法是将大数据流程或设施与应用通过现有的接口连接起来，而不是那些用来直接进行文件系统级操作的。后一种类型的接口会产生可观的增量式开发工作，如果是在这个层面来写，要想将应用从一个大数据服务或设施迁移至另一个几乎是不可能的。
上下文、状态及事务性行为
事务就是工作的上下文，一个从业务角度产生流程步骤的逻辑序列。在确定是SOA还是REST最适合大数据应用时，第一个问题是事务性工作是否包含在大数据组件之内，或者大数据引用在事务中是否跨多个组件传播。第一种情况下，RESTful接口可轻易部署。而在第二种情况下，要想用REST,就得需要某种事务状态控制的机制。而SOA这两种情况都很容易处理。
在进行大数据的SOA和REST决策时，安全和治理也是很重要的点。SOA的安全、访问日志及控制是显式的，且与用户目录和应用控制是高度集成在一起的。而REST的安全和访问控制机制则可能是在外部应用的。这有可能是将大数据访问包装进SOA里面的一个有力的理由，即便在REST使用是在大数据产品级这种层次上也是如此。如果采用RESTful模型的话，必须明确如何建立起能通过正式治理评审的大数据安全。大多数用户会吸收VPN或SSL级的安全，但还会通过网络级的应用访问安全来增强。
最后，小心不要暴露过度。大多数情况下，大数据服务可分为两类-实际的数据访问服务以及数据服务平台管理和控制服务。所有的现代大数据架构都支持这两种，但因为平台管理和控制往往被视为是技术过程而非应用过程，其支持往往牵涉到通过简单的REST接口进行低级的功能访问。大数据管理服务应该尽量少直接暴露给应用开发者或用户，因为会导致相当重大错误的风险。
在需要平台管理工具为大数据使用进行准备时，最好是将这些功能在大数据适配器组件内实现，为应用开发者建立一个更容易的接口来使用，并确保在大数据分析开始之前永远都先经历必要的平台管理步骤。
为架构师和大数据专家预留对平台管理API的访问将是必要的，这样能让他们在日常的数据仓储维护任务中用到。部分用户建议对低级的平台管理API进行抽象，这样的话哪怕是平台管理实践也能跨多个实现应用，但经验告诉我们，要想在这种层次上建立有用的通用实践是很困难的。最好的做法有可能是就让专家和架构师在需要时采用特定的平台管理API就行了。
一旦大数据SOA/REST评审完成，永远要记得把这两种截然不同的API风格的结果与一般政策对照一下。一种工具被创建出来时，需要的绝不仅仅是确立的API基线支持，还包括不同的实践，要预料到更高层面的风险。确保在进行下去之前对风险进行了评估。
