restful接口总结

1. 所有东西都是资源（Resource）

所有要给API操作的对象都只能是资源。不管实际上存在的，还是抽象上的。所有资源都会有一个不变的标识（ID），对资源的任何API操作都不应该改变资源的标识。资源和其他资源会有关系，资源与资源的关系通过资源的标识来引用。

2. 规范对资源的操作，最好只包括CRUD

CRUD指创建（Create），读取（Read）， 更新（Update），删除（Delete）

通常对资源的操作只包含CRUD是不可能的，CRUD里甚至连查找的操作的都没有。但这不妨碍我们对Rest的理解，Rest提出的要求是，对资源的操作都应该是统一的，不管是操作哪种类型的资源，API都应该是一致的。这样当调用API的客户端知道某种资源的时候，它不需要去学习对这个资源该怎么操作，因为对所有资源的操作都是一致的，它们都应该支持CRUD操作，以及一些其他操作，比如list（用来查找，或者列出所有资源）， merge（部分更新资源，这应该是唯一的不操作资源所有内容的API）。

3. 无状态性

无状态性 无 状态性是在客户－服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的，即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性（无状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理当前 request，而不必了解所有的request历史），可靠性（无状态性减少了服务器从局部错误中恢复的任务量），可伸缩性（无状态性使得服务器端可以 很容易的释放资源，因为服务器端不必在多个request中保存状态）。同时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上的共享上 下文中，因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。

4. 统一风格，统一接口

REST 架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对 资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。

5. REST的设计准则

REST架构是针对Web应用而设计的，其目的是为了降低开发的复杂性，提高系统的可伸缩性。REST提出了如下设计准则：

网络上的所有事物都被抽象为资源（resource）；
每个资源对应一个唯一的资源标识符（resource identifier）；
通过通用的连接器接口（generic connector interface）对资源进行操作；
对资源的各种操作不会改变资源标识符；
所有的操作都是无状态的（stateless）。

 REST的设计的优点

1. 轻量，直接基于http，不再需要任何别的诸如消息协议。get/post/put/delete为CRUD操作

2. 面向资源，一目了然，具有自解释性。

3. 数据描述简单，一般以xml，json做数据交换。

4. 无状态，在调用一个接口（访问、操作资源）的时候，可以不用考虑上下文，不用考虑当前状态，极大的降低了复杂度。

5. 简单、低耦合

RESTful风格API有什么缺点

一个适用于简单操作的接口规范而已，无规矩不成方圆，复杂操作并不适用，还是看业务发展需求的

适合CRUD并且只适合 CRUD，有的浏览器可能不支持POST、GET之外的提交方式，要特殊处理，API容易给让误解中能进行增、删、查、改等操作