使用REST而非SOAP，对于移动应用的最大好处是什么？

　　如果你曾经读过，或参与过真正的“RESTafarian”讨论的话，你很可能听说过表述性状态转移（REST）是web的架构这种说法，另外对此也有很多其它的说法。

　　REST是最适合基于浏览器的交互的，对此是没有争论可言的。浏览器和引擎在后面，用于融会他们所处理的内容中的链接的，同时也给各种可能反应类型提供一组处理程序。对浏览器编程语言占主导地位的是JavaScript，让我们面对它，并且在JavaScript中创建简单对象访问协议（SOAP）客户端，这是所有人都想做的事。我们甚至抛弃了使用可扩展标记语言（XML），转而投入JSON的怀抱中。

　　在谈及关于移动应用的问题时，我为什么要讨论web浏览器？我最先提出web浏览器的原因有两个。

　　首先，移动应用确实有两个主要模型：本地的和包装的移动web。本地应用的构建是完完全全使用语言、本地库和移动操作系统涉及到的工具包。例如iOS设备，它使用的是对象C及其库，以及苹果为iOS提供的工具包。表示逻辑是作为应用程序的一部分，安装在设备上的。

　　包装的移动web应用只使用包装web浏览器的本地组件，还给设备功能和浏览器之间提供了一个桥梁，作为交互时设备的照片库。大量的表示逻辑不随着应用程序的安装而安装，而是当应用程序运行时，通过网络下载。当使用这个样式时，我们回到了典型的web方法，使用JavaScript，而没有采用SOAP。

　　但是本地应用呢？为什么不能用SOAP？Android和iOS都有第三方库，使得调用SOAP　Web服务更容易，但是在外部却没有本地支持给它。这并不奇怪，iOS作为对象C扎根于Mac桌面编程，而SOAP扎根于企业集成。但对于Android就有点不一样了，因为Java是应用开发的第一个支持语言。

　　这可以归结为是一种普遍性和简单性。首先，虽然在外部本地平台不支持SOAP，但他们却支持HTTP和XML，所惟普遍性是存在的。在事情的简单性方面，XML确实比SOAP好，在包装的移动web应用情况下，JavaScript比XML好。

　　尽管REST并不只涉及到JSON和XML，也涉及到所有浏览器和平台本地可以处理的媒体类型。如果我可以回到一个字节流，并使它关闭浏览器功能或本机表示组件，而不是通过类似于SOAP的信封来传输，事情并不简单，但是他们也不会是处理器密集型的，这意味给终端用户一个着更好的电池寿命。