REST和SOAP

什么是REST？

REpresentational State Transfer (REST) 是一种架构原则，REST定义了应该如何正确地使用Web 标准（例如 HTTP 和 URI）来定义你的服务端接口。其中将 web 服务视为资源，可以由其 URL 唯一标识。RESTful Web 服务的关键特点是明确使用 HTTP 方法来表示不同的操作的调用。

REST要解决什么问题？

网站服务API的早期标准就是SOAP，SOAP的本质还是提供的是异构化接口，虽然有SWDL，但是SWDL只是描述文档，并没有改变“服务异构化API”这个事实。所以基于SOAP的服务五花八门，显然不利于网络时代的通用共享的需求，而“通用共享”就意味着标准化。

REST就是这种标准化需求的产物。
REST的具体技术实现思路就是：以HTTP协议为标准，改造网站API。

REST Web 服务的四个基本设计原则

由于是以HTTP标准为中心，所以REST服务具有HTTP特征，
REST Web 服务，其具体实现应该遵循四个基本设计原则：

1.显式地使用 HTTP 方法

REST 的基本设计原则对典型 CRUD 操作使用 HTTP 协议方法：
 POST - 创建资源
 GET - 检索资源
 PUT – 更新资源
 DELETE - 删除资源

统一接口也使得所有理解 HTTP 应用协议的组件能与你的应用交互。通用客户程序（generic client）就是从中受益的组件的例子，例如 curl、wget、代理、缓存、HTTP 服务器、网关还有 Google、Yahoo!、MSN 等等。

2. 目录结构式的 URI

也叫“为所有“事物”定义 ID”，通常，值得被 URI 标识的事物——资源——要比数据库记录抽象的多。例如，一个定单资源可以由定单项、地址以及许多其它方面（可能不希望作为单独标识的资源暴露出来）组成。标识所有值得标识的事物，领会这个观念可以进一步引导你创造出在传统的应用程序设计中不常见的资源：一个流程或者流程步骤、一次销售、一次谈判、一份报价请求——这都是可以被标识的资源。

从对资源寻址的客户端应用程序的角度看，URI 决定了 REST Web 服务将具有的直观程度，REST Web 服务 URI 的直观性应该达到很容易猜测的程度。 将 URI 看作是自身配备文档说明的接口，开发人员只需很少（如果有的话）的解释或参考资料即可了解它指向什么，并获得相关的资源。 为此，URI 的结构应该简单、可预测且易于理解。
实现这种级别的可用性的方法之一是定义目录结构式的 URI。 此类 URI 具有层次结构，其根为单个路径，从根开始分支的是公开服务的主要方面的子路径。 根据此定义，URI 并不只是斜杠分隔的字符串，而是具有在节点上连接在一起的下级和上级分支的树。 例如，在一个收集从 Java 到报纸的各种主题的讨论线程服务中，您可能定义类似如下的结构化 URI 集合：http://www.myservice.org/discussion/2008/12/10/{topic}

根 /discussion 节点之下第一个路径片段是四个数字的年份，第二个路径片断是两个数字的日期，第三个片段是两个数字的月份，最后有一个 /topics 节点。 该节点之下有一系列主题名称，例如闲谈、技术等等，每个主题名称指向某个讨论线程。 在此结构中，只需在 /topics/ 后面输入某个内容即可容易地收集讨论线程。
此示例非常直观。

3.支持 XML、JSON等多种数据传输格式

多数据传输格式支持，减少了各个服务之间数据格式转换的麻烦。
对于网络数据来说，数据的Representation必须是通用类型，而不能用int、string、class这类语言局限型数据格式，所以对于资源来说，就是总要通过某种文本格式反应其内容，文本可以用txt格式表现，也可以用HTML格式、XML格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现；JSON是现在最常用的资源表示格式。

RUI可以用XML、JSON、XHTML等任意一种数据格式来描述、并在网络上传输，这使得服务可由运行在不同平台和设备上并采用不同语言编写的各种各样的客户端所使用。 使用 MIME 类型和 HTTP Accept Header 是一种称为内容协商 的机制，这种机制允许客户端选择适合于它们的数据格式，并最小化服务与使用服务的应用程序之间的数据耦合，避免了使用JSON数据格式的客户在JSON和SOAP规定的XML之间的格式转换。

4.无状态性（Stateless）

HTTP 协议从本质上说是一种无状态的协议，客户端发出的 HTTP 请求之间可以相互隔离，不存在相互的状态依赖。基于 HTTP 的 ROA，以非常自然的方式来实现无状态服务请求处理逻辑。对于分布式的应用而言，任意给定的两个服务请求 Request 1 与 Request 2, 由于它们之间并没有相互之间的状态依赖，就不需要对它们进行相互协作处理，其结果是：Request 1 与 Request 2 可以在任何的服务器上执行。
无状态性可以带来两大好处：
1）REST 要求状态要么被放入资源状态中，要么保存在客户端上。或者换句话说，服务器端不能保持除了单次请求之外的，任何与其通信的客户端的通信状态。这样做的最直接的理由就是可伸缩性—— 如果服务器需要保持客户端状态，那么大量的客户端交互会严重影响服务器的压力。
2）服务器集群可以支持无缝请求
无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器。一个客户端从某台服务器上收到一份包含链接的文档，当它要做一些处理时，这台服务器宕掉了，可能是硬盘坏掉而被拿去修理