RESTFUL

RESTFUL 不仅仅是指API ，而是一种== 架构风格 ==，中文名叫做== 表述性状态转移 ==。 ==核心在于 无状态 ==，其实就是== 服务端只维护资源的状态 ，而 客户端来维护会话的状态 ==，会话的状态就是指当前这个会话进行到哪一步了。== 这样的话客户端进行调用的时候，不是去想过程是如何操作的，而是去以资源状态的结果为核心。 == 比如要访问下一页数据，客户端已经记录了当前在哪一个页面了，所以他 只需要告诉服务端我需要访问哪一个页面即可，而不是告诉服务端我要访问下一页。 总结就是 RestFul不仅仅是一种API，而是一种架构模式，主要面向的是资源，提供的是无状态服务 ，==有利于横向扩展做高并发的==。

---

然而 RESTful 可不仅仅是指 API，而是一种架构风格 ，全称 Representational State Transfer， 表述性状态转移 ，来自一篇重要的论文《架构风格与基于网络的软件架构设计》（Architectural Styles and the Design of Network-based Software Architectures）。 == 所谓的无状态，其实是服务端维护资源的状态，客户端维护会话的状态 == 按照这种思路，**==对于 API 的设计，就慢慢变成了以资源为核心，而非以过程为核心。==**也就是说， 客户端只要告诉服务端你想让资源状态最终变成什么样就可以了，而不用告诉我过程，不用告诉我动作。 还是文件目录的例子。客户端应该访问哪个绝对路径，而非一个动作，我就要进入某个路径。再如，库存的调用，应该查看当前的库存数目，然后减去购买的数量，得到结果的库存数。这个时候应该设置为目标库存数（但是当前库存数要匹配），而非告知减去多少库存。 这种 API 的设计需要实现幂等，因为网络不稳定，就会经常出错，因而需要重试，但是一旦重试，就会存在幂等的问题，也就是同一个调用，多次调用的结果应该一样，不能一次支付调用，因为调用三次变成了支付三次。不能进入 cd a，做了三次，就变成了 cd a/a/a。也不能扣减库存，调用了三次，就扣减三次库存。 但是 SOAP 的 XML 正文中，是可以放任何动作的。例如 XML 里面可以写 < ADD >，< MINUS > 等。这就方便使用 SOAP 的人，将大量的动作放在 API 里面。 RESTful 没这么复杂，也没给客户提供这么多的可能性， 正文里的 JSON 基本描述的就是资源的状态，没办法描述动作，而且能够出发的动作只有 CRUD，也即 POST、GET、PUT、DELETE，也就是对于状态的改变。 SOAP 过于复杂，而且设计是面向动作的，因而往往因为架构问题导致并发量上不去。 RESTful 不仅仅是一个 API，== 而且是一种架构模式，主要面向资源，提供无状态服务 ==，有利于 横向扩展应对高并发。