每个移动平台都有各自的API技术架构。移动平台开发API通常分为两类：平台API指的是移动设备自有的操作系统和中间设备，服务API指的是访问web主机所需的资源。
API中的新机遇后端即服务，是服务API模型的扩展。BaaS的目标是将移动应用常见的、有用的元素，如存储、身份管理、社会网络集成、图像增，强转换为具象状态传输(REST)Web服务，根据应用程序调用的需要，将这些服务传递到移动应用后端。
概念上，BaaS与软件即服务(SaaS)和平台即服务(PaaS)类似：都为Web提供了一种服务功能。SaaS所提供的是应用程序或者应用 程序组件，Salesforce.com的CRM应用是一个很好的例子。PaaS提供一系列的服务，可以构建一套完整的虚拟操作系统，微软的 Windows Azure是最著名的PaaS例子。
BaaS介于两者中间，它可以提供和PaaS一样的功能，但却不是一个完整的编程平台。像SaaS一样，具有面向市场或者应用于各行业的功能。不过，在所有情况中，BaaS最终的目的是提升移动开发。
实施BaaS
成功的BaaS需要有针对性的商业案例和谨慎的实施与展望来支持移动开发实践。如今大多数BaaS采用覆盖许多领域的横向部署，可以处理众所周 知的问题例如社交网络集成。随着着这些类型BaaS的实施而来的问题是如此明显，那就是不可避免的竞争，如此基础的东西以至于区分是很难的。例如，云计算 供应商很有可能转移到存储和用户识别相关的BaaS服务中，社交网络公司也会提供社交网络BaaS集成功能。
垂直市场中开发人员已具备了技能、人脉和软件产品，此市场对于BaaS新机遇非常有用。在水平市场中，数据分析和还原工具，或者预测和规划工具是BaaS良好的选择。
从技术上讲，BaaS关键问题是要保持REST Web服务模型接口的优势。这些接口呈现出一个简单的PUT或GET事务处理模式，但并不会一直保持在调用的处理状态中。多数PUT/GET方法显示出了 他们自己的服务API，作为RESTful 接口，这些接口使用XML数据结构来接收和响应。XML处理是一件琐碎的事情，然而，在每个目标移动设备中，接受一个简单的数据结构或者提供编程逻辑来重 复使用该界面都会有所帮助。
创建一个BaaS服务，拥有正确功能级别的粒度，也同样重要。移动用户通常希望设备能够快速响应一个请求，而且有一些接口时间问题：将具有较长 执行时间的复杂功能转移到一个单独的服务上是不合适的。因为RESTful接口预计是无状态的，因此在把复杂功能转化为一系列可以单独使用的元素时要高度 注意，但是当需要时这些功能又可以聚集到一起。
每个请求必须是独立的，并且可以将数据反馈给特定的需求。如果稍后还会需求，就必须将其存储到设备中，或者通过设备返回、维护并更新。
传递PaaS方法
或许，对于开发商而言BaaS最重要的一面是与PaaS间的关系。任何因搜索、社交网络或者云管理面想起API的开发商都知道，多个API通常 会形成一个生态系统，如果该系统发展的足够强大，就可以实现平台功能，例如PaaS。一些无关联的BaaS API也不那么令人信服，例如，整个BaaS系统都旨在支持企业间的移动社交网络协同运行。例如，流行的开源博客和聊天室工具可以建立在统一的交流和协作 平台上，通过增强API来进行语音和视频对话。
BaaS将会引出移动开发后台服务的系统化观点，该观点实际目的是要创建一个移动导向的PaaS平台。开发商、运营商和企业都需要考虑这种发展状况，因为与个人API相比，BaaS工具的协作和共生收集对于开发商和消费者会更有价值。
BaaS活动会促进开发商对云计算的关注，这意味着会实现更快的服务和增加手机厂商间的竞争。但是像云计算的潮流一样，BaaS还处于前期阶段，其中尚存在一个完成的移动世界。
