图片来自http://www.dili360.com/
RESTful
百度百科上说：RESTful一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
wikipedia上说：(REpresentational State Transfer, REST)是一种架构风格，它定义了一组基于HTTP的约束和属性。符合REST架构风格或RESTful 的Web服务提供了Internet上的计算机系统之间的互操作性。遵从REST的web服务允许通过使用统一和预定义的无状态请求来访问和操作web系统的资源。【翻译不准确请多多包含】
需要注意的是，具象状态传输是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准。
- 资源是由URI来指定。
- 对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、 POST、PUT和DELETE方法。
- 通过操作资源的表现形式来操作资源。
- 资源的表现形式则是XML或者HTML，取决于读者是机器还是人，是消费web服务的客户软件还是web浏览器。当然也可以是任何其他的格式。
指导性约束定义了一个RESTful系统。这些约束限制了服务器处理和响应客户请求的方式，以便通过在这些约束内操作，服务获得期望的非功能属性，例如性能，可伸缩性，简单性，可修改性，可见性便携性和可靠性。如果某个服务违反了任何所需的约束条件，则不能将其视为RESTful。
客户端 - 服务器【客户端 - 服务器模型】
客户端 - 服务器约束背后的原则是分离关注点。将用户界面问题与数据存储问题分开可以改善跨多个平台的用户界面的可移植性。它还通过简化服务器组件来提高可伸缩性。然而，对网络而言，最重要的可能是分离允许组件独立发展，从而支持多个组织域的Internet规模需求。
无状态【无状态协议】
客户端 - 服务器之间的通信受限于在请求之间没有客户端上下文存储在服务器上。来自任何客户端的每个请求都包含为请求提供服务所需的所有信息，并且会话状态保存在客户端中。会话状态可以由服务器传输到另一个服务（如数据库），以维持持续状态一段时间并允许进行身份验证。客户端在准备好转换到新状态时开始发送请求。尽管一个或多个请求未完成，但客户端仍处于转换中。每个应用程序状态的表示包含下次客户机选择启动新状态转换时可能使用的链接。
可缓存性【Web缓存】
就万维网而言，客户和中介可以缓存响应。因此，响应必须隐含地或明确地将其自身定义为可缓存或不阻止客户端响应于进一步的请求而重用过时或不适当的数据。管理良好的缓存部分或完全消除了一些客户端 - 服务器交互，进一步提高了可伸缩性和性能。
分层系统【分层系统】
客户通常无法判断它是直接连接到最终服务器还是直接连接到中间人。中介服务器可以通过启用负载平衡和提供共享缓存来提高系统可扩展性。他们也可能会执行安全策略。
统一界面
统一的接口约束是任何REST服务设计的基础。它简化和分离了架构，使每个部分独立演变。这个统一接口的四个约束是：
-
请求中的资源标识
在请求中标识各个资源，例如在基于Web的REST系统中使用URI。资源本身在概念上与返回给客户端的表示分离。例如，服务器可以从其数据库发送数据为HTML，XML或JSON，其中没有一个是服务器的内部表示。 -
通过表示进行资源处理
当客户端持有资源的表示形式（包括附加的任何元数据）时，它具有足够的信息来修改或删除资源。 -
自描述性消息
每条消息都包含足够的信息来描述如何处理消息。例如，要调用哪个解析器可以通过Internet媒体类型（以前称为MIME类型）指定。 -
超媒体作为应用程序状态的引擎（HATEOAS）
在访问REST应用程序的初始URI（类似于访问网站主页的人类Web用户）后，REST客户端应该能够动态地使用服务器提供的链接来发现所需的所有可用操作和资源。随着访问的进行，服务器以包含超链接的文本进行响应，该超链接指向当前可用的其他操作。客户端不需要对关于REST服务的结构或动态的信息进行硬编码。
RESTful API
刚入门php的时候，不知道这么多道道，觉的能访问这个文件了就算成成功了。那时候URL是这样的：
https://example.com/balabala.php?resources=233&fdsafdafdfa=......
后来，接触第一款框架Laravel，突然看到这种URL：
https://example.com/resources/233/fdsafdafdfa/.......
顿时觉的眼前一亮，舒服。但是不知道这两者之间有啥区别，随着框架的一步步的深入使用和学习。首先是nginx/apache配置方面的问题【比较老的框架我就不知道是什么情况了】，没有使用框架的时候，是使用web服务器来进行访问PHP文件URL如下：
test/ ----- 项目文件夹
├── Cl.php ----- url：http://www.test.com/Cl.php?param=...
├── index.php
└── te
└── iiii.php ----- url: http://www.test.com/te/iiii.php?param=...
使用框架之后，nginx配置统一指向public文件夹下的index.php入口文件。URL解析的工作不再由web服务器负责。而是改为使用PHP自身来负责，根据相应的URL如:http://www.test.com/id/1结合mvc或者是其他的设计模式来进行资源的解析和加载【具体的方式这里不提，请自行查阅文档】。
遵循REST架构约束的 Web服务API称为RESTful API。基于HTTP的RESTful API定义了以下几个方面：
- 基本URL，例如
http://api.example.com/resources - 定义状态转换数据元素的互联网媒体类型（例如： Atom, microformats, application/vnd.collection+json）。当前表示告诉客户如何编写转换到所有下一个可用的应用状态 这可以像URL一样简单，也可以像Java applet一样复杂。
- 标准的HTTP方法（例如，OPTIONS，GET，PUT，POST和DELETE）
| (URL) | GET | PUT | PATCH | POST | DELETE |
|---|---|---|---|---|---|
https://api.example.com/resources/ |
从服务器取出资源（一项或多项）。 | 在服务器更新资源（客户端提供改变后的完整资源）。 | 在服务器更新资源（客户端提供改变的属性）。 | 在服务器新建一个资源。 | 从服务器删除资源。 |
下面是一些URL示例
这样
* GET /tickets - Retrieves a list of tickets
* GET /tickets/12 - Retrieves a specific ticket
* POST /tickets - Creates a new ticket
* PUT /tickets/12 - Updates ticket #12
* PATCH /tickets/12 - Partially updates ticket #12
* DELETE /tickets/12 - Deletes ticket #12
或者这样
* GET /tickets/12/messages - Retrieves list of messages for ticket #12
* GET /tickets/12/messages/5 - Retrieves message #5 for ticket #12
* POST /tickets/12/messages - Creates a new message in ticket #12
* PUT /tickets/12/messages/5 - Updates message #5 for ticket #12
* PATCH /tickets/12/messages/5 - Partially updates message #5 for ticket #12
* DELETE /tickets/12/messages/5 - Deletes message #5 for ticket #12
参考资料：
阮一峰RESTful API设计指南
Roy Thomas Fielding论文地址：Representational State Transfer (REST)
时：2018-04-23
网友评论