RESTFUL

起源

REST概念由HTTP 1.1 负责人，罗伊·菲尔丁（Roy Fielding）提出。REST是“表征状态转移”（Representational State Transfer）的缩写。REST相较于HTTP，类似于接口和实现的关系。

表征

用户和信息交互时的表示形式。用户发送请求，是获取html还是获取pdf等。

状态

用户和信息交互时，产生的上下文信息。例如：用户翻页到了第几页。

转移

服务端通过某种形式，改变用户的状态。例如：用户获取到下一页的信息。

核心特征

服务端和客户端分离

将用户界面和服务存储逻辑分离开来，有助于提高用户界面的可移植性。

无状态

服务端不负责维护状态。客户端保存状态，发起请求时，携带状态。服务端根据客户端携带的状态进行业务处理。

可缓存

客户端和服务端之间的代理，将部分请求进行缓存，减少交互。

分层系统

客户端不需要知道请求最终到了哪台服务器，由中间服务器提供负载均衡。

统一接口

面向资源编程，具体的动作由HTTP提供。HTTP提供了GET、HEAD、POST、PUT、DELETE、TRACE、OPTIONS 七种基本操作。

按需代码

可选原则。指的是将可执行的软件程序，由服务端发送到客户端的技术。

不足和争议

面向资源编程只适合CRUD，只有面向对象，面向过程适合复杂的业务逻辑

HTTP的GET、POST、PUT、DELETE方法让人联想到CRUD，但是REST涵盖的内容不止于此。

比如对于删除操作，也可以使用自定义方法。

POST /api/user/id:delete

REST 与 HTTP 完全绑定，不适用于要求高性能传输的场景中

HTTP是应用层协议，REST的设计是依赖HTTP的协议头、请求方法、状态码。无法用做传输层协议。

REST 不利于事务支持

对于事物的理解：

• 如果是数据库的ACID的事物，这个分布式的问题，不是REST的问题。

• 如果是指通过服务协议或架构，在分布式服务中，获得对多个数据同时提交的统一协调能力（2PC/3PC），那 REST 确实不支持。

• 如果是指希望保证数据的最终一致性，说明已经放弃刚性事务了。这才是分布式系统中的主流，使用 REST 肯定不会有什么阻碍。

REST 没有传输可靠性支持

REST 并没有提供对传输可靠性的支持。在 HTTP 中，发送出去一个请求，通常会收到一个与之相对的响应。但是，如果没有收到任何响应，那就无法确定消息到底是没有发送出去，还是没有从服务端返回回来。

应对传输可靠性最简单粗暴的做法，就是把消息再重发一遍。这种简单处理能够成立的前提，是服务具有幂等性（Idempotency）。