什么是REST？

这里是修真院前端小课堂，每篇分享文从

【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

八个方面深度解析前端知识/技能，本篇分享的是：

【什么是REST？】

1.背景介绍

要解释什么是REST，你应该先了解什么是API（Application Programming Interface,应用程序编程接口）， 形象一点说就是像一个公司比如腾讯，阿里巴巴之类，他们可以提供一个API，然后我们或者一些其他的小公司可以编一个软件去跟这个接口（API）进行相连或交互。

举个例子，比如你可以用手机的其他软件分享内容到微信朋友圈或者新浪微博，这些软件就是与微信和微博的api进行了交互。知道了API，那么就容易理解REST了。它是一种架构风格，腾讯公司或其他公司建立API时要遵守的一种规则/风格，当然也有其他规则可以用。

要具体知道什么是REST，我们又必须提到Web，因为REST是以Web为平台的。Web是分布式信息系统为超文本文件和其他对象（资源）提供访问入口。

资源是Web架构的关键点,需要3个操作:

识别(identify)，表示(represent)，交互(interact with)

通过这三个操作，又引出三个概念:

1.uri（统一资源标识符包括url和urn）识别资源；

2.representation （例如html，图片，视频等等）表示资源；

3.通过协议（包括http，ftp等等）与资源进行交互。

所以REST就是选择通过使用http协议和uri，利用client/server model对资源进行CRUD(Create/Read/Update/Delete)增删改查操作。

2.知识剖析

REST不是"rest"这个单词，而是Resource Representational State Transfer的缩写：通俗来讲就是：资源在网络中以某种表现形式进行状态转移。分开来讲：

1.Resource：资源，即数据（网络的核心）。

2.Representational：某种表现形式，比如用JSON，XML，JPEG等；

3.State Transfer：状态变化。通过HTTP动词实现。

REST描述的是在网络中client和server的一种交互形式；REST本身不实用，实用的是如何设计 RESTful API（REST风格的网络接口；

Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。

用HTTP协议里的动词来实现资源的添加，修改。

Server和Client之间传递某资源的一个表现形式，比如用JSON，XML传输文本，或者用JPG，WebP传输图片等。

用 HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误等。

Web端不再用之前典型的PHP或JSP架构，而是改为前段渲染和附带处理简单的商务逻辑。Web端和Server只使用上述定义的API来传递数据和改变数据状态。格式一般是JSON。

对于资源的具体操作类型，由HTTP动词表示。常用的HTTP动词有下面五个（括号里是对应的SQL命令）：

1.GET（SELECT）： 从服务器获取资源(一项或多项)

2.POST（CREATE）： 在服务器新建一个资源

3.PUT（UPDATE）： 在服务器更新资源（客户端提供改变后的完整资源）

4.PATCH（UPDATE）： 在服务器更新资源（客户端提供改变的属性）

5.DELETE（DELETE）：从服务器删除资源。

比如：

GET /zoos：列出所有动物园

POST /zoos：新建一个动物园

GET /zoos/ID：获取某个指定动物园的信息

PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息

PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）

DELETE /zoos/ID：删除某个动物园

GET /zoos/ID/animals：列出某个指定动物园的所有动物

DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物

3.常见问题

Server的API如何设计才满足RESTful要求?

URL root:

https://example.org/api/v1/*

https://api.example.com/v1/

API versioning:

可以放在URL里面，也可以用HTTP的header：/api/v1/

URI使用名词而不是动词，且推荐用复数。

保证HEAD和GET方法是安全的，不会对资源状态有所改变（污染）。

资源的地址推荐用嵌套结构：

GET /friends/10375923/profile

为什么要用RESTful结构呢？

大家都知道"古代"网页是前端后端融在一起的。在之前的桌面时代问题不大，但是近年来移动互联网的发展，各种类型的Client层出不穷，RESTful可以通过一套统一的接口为Web,iOS和Android提供服务。另外对于广大平台来说，比如Facebook，微博开放平台，微信公共平台等，它们不需要有显式的前端，只需要一套提供服务的接口。

REST的优点和限制

1.客户-服务器（Client-Server）客户端服务器分离

优点:

提高用户界面的便携性（操作简单）

通过简化服务器提高可伸缩性（高性能，低成本）

允许组件分别优化（可以让服务端和客户端分别进行改进和优化）

2.无状态（Stateless）

从客户端的每个请求要包含服务器所需要的所有信息

优点:

提高可见性（可以单独考虑每个请求）

提高了可靠性（更容易从局部故障中修复）

提高可扩展性（降低了服务器资源使用）

3.缓存（Cachable）

服务器返回信息必须被标记是否可以缓存，如果缓存，客户端可能会重用之前的信息发送请求。

优点:减少交互次数,减少交互的平均延迟。

4.分层系统（Layered System）

系统组件不需要知道与他交流组件之外的事情。封装服务，引入中间层。

优点:限制了系统的复杂性,提高可扩展性。

5.统一接口（Uniform Interface）

优点:提高交互的可见性,鼓励单独改善组件。

6.支持按需代码（Code-On-Demand）

优点:提高可扩展性

4.扩展思考

举个例子：

例如我订阅了一个人的博客，想要获取他发表的所有文章（这里『他发表的所有文章』就是一个资源Resource）。于是我就向他的服务发出请求，说『我要获取你发表的所有文章，最好是atom格式的』，这时候服务器向你返回了atom格式的文章列表第一页（这里『atom格式的文章列表』就是表征Representation）。

你看到了第一页的页尾，想要看第二页，这时候有趣的事情就来了。如果服务器记录了应用的状态（stateful），那么你只要向服务询问『我要看下一页』，那么服务器自然就会返回第二页。类似的，如果你当前在第二页，想服务器请求『我要看下一页』，那就会得到第三页。但是REST的服务器恰恰是无状态的（stateless），服务器并没有保持你当前处于第几页，也就无法响应『下一页』这种具有状态性质的请求。因此客户端需要去维护当前应用的状态（application state），也就是『如何获取下一页资源』。

当然，『下一页资源』的业务逻辑必然是由服务端来提供。服务器在文章列表的atom表征中加入一个URI超链接（hyper link），指向下一页文章列表对应的资源。客户端就可以使用统一接口（Uniform Interface）的方式，从这个URI中获取到他想要的下一页文章列表资源。上面的『能够进入下一页』就是应用的状态（State）。服务器把『能够进入下一页』这个状态以atom表征形式传输（Transfer）给客户端就是表征状态传输（REpresentational State Transfer）这个概念。

5.参考文献

JSON的编码规范：http://jsonapi.org/format/

怎样用通俗的语言解释REST，以及RESTful？：https://www.zhihu.com/question/28557115

“我们相信人人都可以成为一个工程师，现在开始，找个师兄，带你入门，学习的路上不再迷茫。

这里是技能树.IT修真院：http://www.jnshu.com，初学者转行到互联网行业的聚集地。"

欢迎加IT交流群565734203与大家一起讨论交流