参考：https://zh.wikipedia.org/wiki/REST
REST: 具象状态传输（英文：Representational State Transfer，简称REST）
要点及标准
- 需要注意的是，REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准。
- 资源是由URI来指定。
- 对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
- 通过操作资源的表现形式来操作资源。
- 资源的表现形式则是XML或者HTML，取决于读者是机器还是人，是消费web服务的客户软件还是web浏览器。当然也可以是任何其他的格式。
REST的要求
- 客户端和服务器结构:通信只能由客户端单方面发起，表现为请求-响应的形式。
- 连接协议具有无状态性:通信的会话状态（Session State）应该全部由客户端负责维护。
- 能够利用Cache机制增进性能:响应内容可以在通信链的某处被缓存，以改善网络效率。
- 一致性的操作界面:通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。
- 层次化的系统:通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。
- 所需代码 - Javascript（可选）:支持通过下载并执行一些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进行扩展
关于状态
应该注意区别应用的状态和连接协议的状态。HTTP连接是无状态的（也就是不记录每个连接的信息），而REST传输会包含应用的所有状态信息，因此可以大幅降低对HTTP连接的重复请求资源消耗。
扫描二维码关注公众号，回复：
310497 查看本文章
应用于Web服务
- 符合REST设计风格的Web API称为RESTful API。它从以下三个方面资源进行定义：
- 直观简短的资源地址：URI，比如：http://example.com/resources/。
- 传输的资源：Web服务接受与返回的互联网媒体类型，比如：JSON，XML，YAML等。
- 对资源的操作：Web服务在该资源上所支持的一系列请求方法（比如：POST，GET，PUT或DELETE）。
下表列出了在实现RESTful API时HTTP请求方法的典型用途。
[1]http://example.com/resources/
http://example.com/resources/142
| 列出URI，以及该资源组中每个资源的详细信息（后者可选）。 | 使用给定的一组资源替换当前整组资源。 | 在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL。 | 删除整组资源。 |
| 获取指定的资源的详细信息，格式可以自选一个合适的网络媒体类型（比如：XML、JSON等） | 替换/创建指定的资源。并将其追加到相应的资源组中。 | 把指定的资源当做一个资源组，并在其下创建/追加一个新的元素，使其隶属于当前资源。 | 删除指定的元素。 |
PUT和DELETE方法是幂等方法。GET方法是安全方法（不会对服务器端有修改，因此当然也是幂等的），GET方法具有幂等性[指多个相同请求返回相同的结果]——如果你发送了一个GET请求没有得到结果，你可能不知道原因是请求未能到达目的地，还是响应在反馈的途中丢失了。幂等性保证了你可以简单地再发送一次请求解决问题。
不像基于SOAP的Web服务，RESTful Web服务并没有“正式”的标准。这是因为REST是一种架构，而SOAP只是一个协议。虽然REST不是一个标准，但大部分RESTful Web服务实现会使用HTTP、URI、JSON和XML等各种标准。
实现举例
例如，一个简单的网络商店应用，列举所有商品，
GET http://www.store.com/products
呈现某一件商品，
GET http://www.store.com/product/12345
下单购买，
POST http://www.store.com/order
<purchase-order>
<item> ... </item>
</purchase-order>
REST的优点
- 可更高效利用缓存来提高响应速度
- 通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
- 浏览器即可作为客户端，简化软件需求
- 相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
- 不需要额外的资源发现机制
- 在软件技术演进中的长期的兼容性更好