首先RESTful 不是技术栈，而是一种软件架构模式，这种模式主要应用的场景是基于网络的应用之间的通信。
REST 全名 Representational State Transfer，表述性状态转移，这个表述指的对象就是资源。资源可以是实体的，也可以是抽象的，只要能被引用到的都可以称为资源。REST里的资源不单指资源，是资源+表现的组合。所有的操作都是基于资源进行的。
资源与URI的关系- 资源既然要拿来表述，就需要能通过一种唯一标识来对不同资源做区分，这种标识就是称为URI（Uniform Resource Identifier）统一资源标识符。
- URI 的设计应对资源的描述是简洁准确的，已下是我总结的 URI 设计的一些原则：1.URI 结尾不应包含 “/”；2.URI 当中的 “/” 必需来指示层级关系；3.URI 字符过长时，用下划线 "_" 或 横线“-” 来分割词组；4.URI 不要包含动词，要采用名词；URI 设计最佳实践没有绝对正确的答案，REST 也是一种规范不是强制性，一切还要自己把握...
RESTful 的使用场景是WEB应用之间的通信，所以这个架构模式就是为API开发而生的，使用RESTful 架构的API 也称为 RESTful API。RESTful API 没有官方标准，但通常满足已下6个导向性约束就算满足条件：
1.客户端/服务器架构：REST 架构由客户端、服务器和资源构成，通过 HTTP 来处理请求。
2.无状态：请求所经过的服务器上不会存储任何客户端内容。与会话状态相关的信息会存储在客户端上。
3.可缓存性：通过缓存，可免去客户端与服务器之间的某些交互。
4.分层系统：客户机与服务器之间的交互可以通过额外的层来进行调解。这些层可以提供额外的功能，如负载均衡、共享缓存或安全防护。
5.按需代码（可选）：服务器可通过传输可执行代码来扩展客户端的功能。
6.统一接口：这项约束是 RESTful API 的设计核心，共涵盖 4 个层面：
（1）识别请求中的资源：请求中的资源会被识别，并与返回给客户端的表示内容分离开来。
（2）通过不同的表示内容来操纵资源：客户端会收到表示不同资源的文件。这些表示内容必须提供足够的信息，以便执行修改或删除操作。
（3）自描述消息：返回给客户端的每个消息都包含充足的信息，用于指明客户端应该如何处理所收到的信息。
（4）将超媒体作为应用状态的引擎：在访问某个资源后，REST 客户端应该能够通过超链接来发现当前可用的所有其他操作。
RESTful API 非常流行，关于它的标准的产生也是意料之中，现在有比较流行的设计规则 OpenAPI 可以参照了。
统一资源接口统一资源接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。使用http方法可以获得安全性和幂等性。安全性是指无论对资源请求多少次，都不会改变资源状态，幂等性是指无论请求多少次，资源返回结果始终是一样的。
| HTTP方法 | 安全性 | 幂等性 |
|---|---|---|
| GET | 安全 | 幂等 |
| POST | 不安全 | 不幂等 |
| PUT | 不安全 | 幂等 |
| DELETE | 不安全 | 幂等 |
请求会返回http状态码，状态码根据请求方法的不同意义会有所不同，已下是常用请求方法状态码的汇总：
200：请求成功
201：创建新资源成功
204：请求成功，但返回内容为空
301：永久重定向
400：请求语法错误
403：服务器拒绝了请求
404：资源未找到
500：服务器内部错误
资源的表述资源是一种信息实体，有多种外在表现形式，资源通过形式表现出来就叫做资源的表述。例如一个资源既可以使用Json 格式表现，也可以使用XML格式。http头部的“contype-type”属性就是指定资源的表现形式的。
资源的状态转移在互联网中，服务端与客户端交互需要用到 http 协议，而 http 协议是一种无状态的协议，客户端如果想修改资源的状态，只能使用 http 的方法，get、post、put、delete 等来对资源的状态进行修改。
总结RESTful 作为现在最通用的 API 设计模式，主要也是现在 WEB 发展的大潮之下，我们的服务和应用需要越来越多的交互，WEB 应用即软件，相比厚重的客户端程序，WEB 应用更加的轻便和高效，越多的数据交互更需要一个通用的交互请求的规范，这也是RESTful 的价值。