网上对于restful的介绍大多都让人感觉十分虚，有些似懂非懂的感觉，所以本篇记录笔者在学习restful过程中的个人理解。
1、restful的定义
restful是一种组织web服务的架构，并不是实现web服务的新架构，重点在组织。又称面向资源的架构，它是一种架构的设计模型，一种规范，好比于API，而不是实现类。
2、restful的优势
先说传统开发，我们一贯的思维习惯是面向操作，好比我要开发一个登录注册的功能，前端将所需要传递给服务器的相关参数塞进url中，后端接收到参数进行处理，能感受到这样的开发是为了登录注册这个操作这个业务逻辑服务而将参数填充。这样的传统开发很显然现今十分适用并且确实能完成优秀的开发，但是可能存在以下问题：当操作模块有交集或依赖的时候，很容易造成uri紊乱，并且uri缺乏规范，可读性很低。而resuful的开发，想要对什么资源进行操作就会对应具体的uri，简洁明了，将开发思维转换成对资源的操作。
面向资源的开发优势很明显：
1）url具有自描述性，高可读性
2）大大降低了视图与资源的耦合
3）可很容易地提供对外接口，利于水平扩展业务
restful的目标是为了创建具有良好扩展性的分布式系统。
3、restful作为架构的约束
restful的定义十分虚，很多开发者仅仅只修改了以下url就称为是restful风格的开发。作为restful风格的开发应满足以下条件：
1）无状态。REST系统中的服务端将不保存客户端的任何信息，这些状态会变成uri交由客户端保存，并且每次与服务端的交互时都提供充足的状态信息。
2）可缓存。恰当的缓存请求内容，来减少服务器与客户端的交互。
3）统一的接口。使用统一的接口来完成客户服务的交互以及各个子系统和服务之间的交互。
再说的具体一些：
1）资源唯一标识。每个资源都有唯一对应的一个标识。
2）资源自描述性。rest系统返回的资源会对自身进行描述，提供如何处理自己的足够信息。如如何进行操作，新增、删除等，所以restful的服务不需要额外的文档或者说明来解释如何操作资源。
3）消息自描述性。同资源一样，消息也需提供如何处理自己的信息。
如此一来，restful的系统不需要关心记录维持用户的任何状态信息，只需要根据客户端传过来的请求来提供相应的资源即可，而客户端也无需关心任何有关资源的信息，根据服务端传来的资源进行相关处理即可。
4、restful系统设计的难点
1）抽象资源。需要辨别及抽象出资源，例如分页，这个“页”就不应为资源的一种。
2）Uri设计。例如商品的uri可以为/api/goods，牙膏的uri为/api/goods/1，而资源下可能还存在子资源，例如牙膏6月份的销售情况，可以为/api/goods/1/sales/1806等。除此之外选用相对路径还是请求参数也是需要考虑的点。
3）对于系统无状态约束的实施。在实际开发过程中完全做到无状态是有相当的难度的，比如登录操作不使用session等记录登录信息，则每次请求都会频繁请求登录大量增加服务器负荷，这与减轻服务器负荷的初衷背道而驰。
5、总结
核心思想：将业务逻辑资源化，例如将商品添加入购物车，其实就是刷新购物车这个资源，感觉像是受到降维打击了一样。
关键词：无状态，面向资源，自描述性
学习过程中看到有博主的这句话，我很喜欢：一个REST系统为资源所抽象出来的uri其实是对用户的一种承诺，但反过来，软件开发人员也很难预知一个资源的各方面特性在将来会发生何种变化而提供一个永远不变的URI。这是难点，但是一切方案和设计都是为了更优质更高效的开发和服务，我是站在almost restful一方的，原则是必须去遵守的，但首先它不能成为你成功的绊脚石。