云時代走進BaaS 移動API現新機遇
每個移動平臺都有各自的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還處于前期階段，其中尚存在一個完成的移動世界。
