什么是REST？

最新推荐文章于 2023-07-26 20:40:14 发布

MazenChan

最新推荐文章于 2023-07-26 20:40:14 发布

阅读量266

点赞数

分类专栏：工具&框架文章标签： rest

原文链接：https://www.jianshu.com/p/350122cf63f2

版权

工具&框架专栏收录该内容

17 篇文章 0 订阅

订阅专栏

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）这个概念。