### **RESTFUL ：表现层状态转移** rest是一组架构约束条件和原则，如果一个框架符合rest的约束条件和原则，则可以称是一种restful架构风格。 #### **1、采用URI标识资源** 每一个资源都有一个唯一标识URI。URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。 URI设计技巧： * 使用_或-来让URI可读性更好 * 使用/来表示资源的层级关系 * 使用?用来过滤资源 URI实例：https://github.com/git/git/pulls?state=closed #### **2、统一的REST接口规范** RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。 如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响。 * GET（SELECT）： 从服务器检索特定资源，或资源列表。 * POST（CREATE）：在服务器上创建一个新的资源。 * PUT（UPDATE）： 更新服务器上的资源，提供整个资源。 * PATCH（UPDATE）：更新服务器上的资源，仅提供更改的属性。 * DELETE（DELETE）：从服务器删除资源。 统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。 在RESTFUL架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的"集合"（collection），所以API中的名词也应该使用复数。 #### **3、资源的表述** 客户端通过HTTP方法可以获取资源，准确来说，客户端获取的只是资源的表述而已。 资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。 例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。 资源的表述包括数据和描述数据的元数据，例如，HTTP头"Content-Type" 就是这样一个元数据属性。 那么客户端如何知道服务端提供哪种表述形式呢? 答案是可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。 #### **4、无状态性** RESTFUL只要维护资源的状态，而不需要维护客户端的状态。对于它来说，每次请求都是全新的，它只需要针对本次请求作相应的操作，不需要将本次请求的相关信息记录下来以便用于后续来自相同客户端请求的处理。即所有的资源都可以URI定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而变化 ***** ### **在thinkphp中的应用：** #### **1、资源控制器** 资源控制器可以让你轻松的创建RESTFUL资源控制器，可以通过命令行生成需要的资源控制器 ``` // 生成index模块的Blog资源控制器 php think make:controller index/Blog 或者 php think make:controller app\index\controller\Blog ``` #### **2、注册路由** thinkPHP5.0支持设置RESTFUL请求的资源路由，方式如下： ``` Route::resource('blog','index/Bog'); ``` 设置后会自动注册7个路由规则，如下： |请求类型 | 路由规则 |对应方法| |---|---|---| | GET | blog |index| | GET | blog/create |create| | POST | blog |save| | GET | blog/:id |read| | GET | blog/:id/edit |edit| | PUT| blog/:id |update| | DELETE| blog/:id |delete|