让php返回204技巧_资深技能专家杨彪你真的理解REST吗

● REST的观点是什么

● 我们为什么须要REST

● 前端渲染和后端渲染的上风是什么

● 什么样的REST才是\"大众正宗\"大众的

REST的观点是什么

● 维基百科 表现层状态转换（REST，英文：Representational State Transfer）是Roy Thomas Fielding博士于2000年在他的博士论文中提出来的一种万维网软件架构风格，目的是便于不同软件/程序在网络（例如互联网）中相互通报信息。

● 知乎 [资源]表现层状态转换（REST，英文：[Resource] Representational State Transfer），普通翻译为：资源在网络中以某种表现形式进行状态转移。

我们为什么须要REST

在前面先容了REST的观点，不过对付初次打仗REST的同学来说，可能会以为晦涩难懂，由于只有几个新的名词观点阐明而已，对付我们来说它又有什么用呢？

在先容REST的浸染之前，我们先理解一下在REST没有涌现之前的Web开拓是什么样的?

早期的Web 项目一样平常是在做事器端进行渲染，做事器进程从数据库获取数据后，然后利用后端模板引擎（比如Velocity、Freemaker 等）或者直接在HTML 模板中嵌入后端措辞（比如JSP、PHP），将数据加载进来天生HTML，然后通过网络传输到用户的浏览器中，末了被浏览器解析成可见的页面。
详细的过程如下图所示：

关注我：私信回答“架构资料”获取往期Java高等架构资料、源码、条记、视频

Dubbo、Redis、设计模式、Netty、zookeeper、Spring cloud、分布式、

高并发等架构技能

做事端渲染

此时大多数做事器架构都是这种 MVC 模式，前端只须要一次HTTP要求就可以返回全体页面内容，加载速率可能会轻微快些。
但是它的缺陷也非常明显，前端写完静态页面，要让后台去套模板，每次前端稍有改动，后台对应的模板页面同时也须要改动，而且页面中可能会包含大量繁芜的 JS代码，比如美工同学（当时的前端）须要通过JS写界面的交互，而后端同学又须要通过JS实现数据的渲染，非常地麻烦。

当然事情麻烦归麻烦，但还不至于引发新的技能革命，而真正推动REST发展的是移动互联网的涌现。
由于多终端设备的兼容性需求，从前的做事端渲染已经很难知足哀求了。
做事端不可能针对每一个Client渲染一套界面，如果做事端只供应须要的数据，而详细界面的渲染完备交给详细的Client来完成，因此催生了REST的发展和遍及。

RESTful可以通过一套统一的接口为 Web、iOS和Android供应做事，其余对付很多平台来说（比如像Facebook，Twiter、微博、微信等开放平台），它们不须要有显式的前端，只须要一套供应做事的接口，于是RESTful便是它们最好的选择。

REST API

前端渲染和后端渲染的上风是什么

随着前端渲染引擎的发展，新兴的Angular，React，Vue等的涌现，真正地实现了前后端分离解耦：前端专注于UI，卖力View和Controller层，后端专注于业务/数据处理，卖力Model层，两端通过设计好的REST API进行交互。

图片来自阿里玉伯的文章

虽然现在前后端分离早已不是什么新鲜话题，不过前后端分离到底有什么样的上风呢？我们可以比拟一下各自的优点。

后端渲染的优点：

● 1、对搜索引擎友好，这样做有利于 SEO。

● 2、加载韶光短，后端渲染加载完成后就直接显示HTML，但前端渲染在加载完成后还须要有段js 渲染的韶光。

前端渲染的优点：

● 1、让前后真个职责更清晰，分工更合理高效。
前后端业务分离，后端只须要供应数据接口，前端在开拓时也不须要支配对应的后端环境，可以通过Mock数据进行并发开拓。

● 2、打算量转移，原来由做事器实行的渲染任务转移给了客户端，这在大量用户访问的时候大大减轻后真个压力。
让后端专注做后端该当做的事情，性能将大大提高，由于做事器做的事情确实减小了。

前后端分离+Node层优点：

● 通过 Node，Web Server 层也是 JavaScript 代码，这意味着部分代码可前后复用，须要 SEO 的场景可以在做事端同步渲染，由于异步要求太多导致的性能问题也可以通过做事端来缓解，结合了前两种模式的优点。

言归正传，前面先容了什么是REST，也先容了它的上风，接下来详细先容REST的详细内容。

什么样的REST才是『正宗』的

无状态原则

遵照REST范式的系统是无状态的，这意味着做事器不须要知道客户端处于什么状态，反之亦然。
这样，纵然没有看到以前的，做事器和客户端都可以理解收到的任何。
这种的无状态约束是通过利用资源来实现的。
资源是Web中的特定名词——它描述了任何你可能须要存储或发送到其他做事的工具或文档。

无状态原则是RESTful架构设计中一个非常主要的原则，无状态是相对付有状态而言的，我们首先看一下什么是有状态的。

Web做事的状态一样平常指的是要求的状态，是客户端和做事端进行交互操作时所留下来的公共信息(比如，用户的信息等)。
这些信息可以被指定在不同的浸染域中（如request、session、application等），常日由做事端来保存这些信息。

而无状态的Web做事是指每一个Web要求都是独立的，做事端没有保存任何客户真个状态信息，以是客户端发送的要求必须包含有能够让做事端理解要求的全部信息。

其余由于REST系统通过资源上的标准操作进行交互，因此它们不依赖于接口的实现，使得RESTful运用程序具有可靠性、快速性和可扩展性。

前后端通信机制

1、要求办法

REST哀求客户端向做事端发出要求以得到或修正做事器上的数据。
要求常日由以下部分组成：

● 一个HTTP动词，它定义了要实行的操作类型

● 一个头部，它许可客户端通报关于要求的信息

● 一条资源的路径

● 一个包含数据的可选主体

（1）对付HTTP动词

在REST系统中我们利用4个基本HTTP动词来与资源进行交互：

● GET - 检索特定资源（通过id）或资源凑集

● POST - 创建一个新资源

● PUT - 更新特定资源（通过ID）

● DELETE - 按ID删除特定资源

（2）对付要求头部

客户端向做事端发送它能够吸收的内容的类型，而该类型是通过一个叫Accept的字段发送的。
通过这种办法可以确保做事端不会发送客户端无法理解或者无法处理的数据。

用于指定Accept字段的类型为MIME类型，它是由一个type和一个subtype通过斜线（/）分隔组成的。
你可以在MDN Web文档中查看更多关于MIME类型的先容。

例如，包含HTML的文本文件类型指定为text/html，而包含CSS的文本文件须要指定为text/css，一样平常的文本文件将被指定为text/plain（如果不指定，则默认值为text/plain）。
如果客户期待的类型为text/css，而吸收到的类型text/plain，那么客户端将无法识别它。
以下列举了其他的type和subtype：

● image — image/png, image/jpeg, image/gif

● audio — audio/wav, image/mpeg

● video — video/mp4, video/ogg

● application — application/json, application/pdf, application/xml, application/octet-stream

（3）对付资源路径

在RESTful API中，每一个要求的动作都必须浸染于一个资源路径上，以是资源路径的设计便是为了让客户端能够理解它所进行的操作是什么。

常日情形下，路径的第一部分该当是资源的复数形式。
RESTful中这种路径嵌套办法大略易读，也更随意马虎理解。
示例如下：

https://www.alipay.com/customers/22/orders/11

该RESTful API指向的路径非常清晰，由于它具有层次性和自描述性。
该示例中，我们查询了id号为22这位顾客的一笔订单，并且该订单的id号为11。

路径必须包含它所须要的能够准确定位它所代表的资源位置的信息。
但是，如果引用的资源为列表或凑集时，就不须要再向POST要求添加id这样的唯一标识了，由于在做事端将为该新工具天生一个唯一标识id的。
例如向顾客凑集中新增一位顾客：

POST https://www.alipay.com/customers

如果我们试图访问单个资源，则须要在路径后面添加一个id，例如通过指定的id来查询一位顾客：

GET https://www.alipay.com/customers/:id

或者，通过指定的id来删除一位顾客：

DELETE https://www.alipay.com/customers/:id

2、吸收内容

在做事器向客户端发送数据有效载荷的情形下，做事器必须content-type在相应的头部包含一个。
这个content-type头域见告客户端它在相应主体中发送的数据的类型。
这些内容类型是MIME类型，就像它们在accept要求头的字段中一样。
该content-type做事器在相应发送回应的客户机中指定的选项之一accept的要求的字段。

例如，当客户端利用此GET要求访问具有资源id23的articles资源时：

GET /articles/23 HTTP/1.1

Accept: text/html, application/xhtml

做事器可能会利用相应头发回内容：

HTTP/1.1 200 (OK)

Content-Type: text/html

这将意味着所要求的内容被返回的相应体用content-type的text/html，该客户表示，将能够接管。

3、返回状态

在做事器向客户端发送数据有效载荷的情形下，做事器必须content-type在相应的头部包含一个。
这个content-type头域见告客户端它在相应主体中发送的数据的类型。
这些内容类型是MIME类型，就像它们在accept要求头的字段中一样。
该content-type做事器在相应发送回应的客户机中指定的选项之一accept的要求的字段。

例如，当客户端利用此GET要求访问具有资源id23的articles资源时：

GET /articles/23 HTTP/1.1

Accept: text/html, application/xhtml

做事器可能会利用相应头发回内容：

HTTP/1.1 200 (OK)

Content-Type: text/html

来自做事器的相应包含状态代码，以提醒客户有关操作成功的信息。
作为开拓职员，您不须要知道每个状态代码（个中有很多），但您该当知道最常见的状态代码以及它们的利用办法：

状态码含义200 (OK)这是成功HTTP要求的标准相应。
201 (CREATED)这是导致成功创建项目的HTTP要求的标准相应。
204 (NO CONTENT)这是成功HTTP要求的标准相应，相应正文中没有任何内容被返回。
400 (BAD REQUEST)由于要求语法缺点，大小过大或其他客户端缺点，无法处理该要求。
403 (FORBIDDEN)客户端没有权限访问此资源。
404 (NOT FOUND)此时无法找到该资源。
它可能已被删除，或尚不存在。
500 (INTERNAL SERVER ERROR)如果没有更多可用的特定信息，则通用答案意外失落败。

对付每个HTTP动词，做事器在成功时应返回预期的状态代码：

● GET - 返回200（OK）。

● POST - 返回201（创建）。

● PUT - 返回200（OK）。

● DELETE - 返回204（无内容）。
如果操作失落败，则返回可能对应于碰着的问题的最详细的状态码。

4、CRUD示例解释

现在我们须要设计一个班级管理的系统，个中须要有班级信息和班级的学生信息。
那我们该怎么为它设计REST接口呢？可以按照以下几点思考：

● 利用什么样的要求办法？

● 做事端返回是什么样的？

● 通过什么样的content-type传输内容？

● 首先定义班级和学生的数据模型如下。

{

“class”: { \公众id\"大众: <Integer>,

“name”: <String>,

}

“num”: <Integer>

}

{

“ student”: {

\公众id\公众: <Integer>,

“name”: <String>,

“age”: <Integer>

}

}

● 接口要求/相应的定义。

GET要求：

接口要求办法传输格式（Content-type）返回状态/classesGETapplication/json200 (OK)/classes/:idGETapplication/json200 (OK)/classes/:id/studentsGETapplication/json200 (OK)/classes/:id/students/:idGETapplication/json200 (OK)

POST要求：

接口要求办法传输格式（Content-type）返回状态/classesPOSTapplication/json201 (CREATED)/classes/:id/studentsPOSTapplication/json201 (CREATED)

PUT要求：

接口要求办法传输格式（Content-type）返回状态/classes/:idPUTapplication/json200 (OK)/classes/:id/students/:idPUTapplication/json200 (OK)

DELETE要求：

接口要求办法传输格式（Content-type）返回状态/classes/:idDELETEapplication/json204 (NO CONTENT)/classes/:id/students/:idDELETEapplication/json204 (NO CONTENT)

本文先容了REST的干系观点，同时先容了我们为什么须要REST，剖析了前端渲染和后端渲染的上风是什么，然后再先容了什么样的REST才是\"大众正宗\"大众的，末了通过一个示例完全的演示了CRUD的操作。