RESTful API浅谈

最新推荐文章于 2022-12-20 15:17:42 发布

转载最新推荐文章于 2022-12-20 15:17:42 发布 · 6.9k 阅读

文章标签：

#REST #RESTful #RESTful API

笔记同时被 2 个专栏收录

21 篇文章

订阅专栏

设计模式

1 篇文章

订阅专栏

本文介绍了REST和RESTful API相关知识。REST全称是Representational State Transfer，是一种设计风格，用URL定位资源，用HTTP描述操作。满足REST约束条件和原则的应用程序或设计就是RESTful，基于此设计的API即RESTful API，它强调利用HTTP标准和特征。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

REST

REST全称是Representational State Transfer，中文翻译的话有很多种说法，比如：表现层状态转化、表述性状态转移、表述性状态传递等等，不管怎么翻译，大致的意思都是：资源在网络中以某种表现形式进行状态转移。

理解“表现层状态转化”:

1. Representational（表现层）

某种表现形式，比如用JSON，XML，JPEG等。我们把"资源"具体呈现出来的形式，叫做它的"表现层"。

2. State Transfer（状态转化）

访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。

互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。他在论文中提到："我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。"

首先要明确一点：REST 实际上只是一种设计风格，它并不是标准。（所以你可以看到网上一大堆的各种最佳实践，设计指南，但是没有人说设计标准）。既然不是标准，我可以遵守，也可以不遵守。

REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力，更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深，但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。所以我们这里描述的REST也是通过HTTP实现的REST。

用一句话来概括REST：

REST就是就是用URL定位资源，用HTTP描述操作。

这句还看不懂的话，没关系，一句不懂的话我换三句来讲，如下：

看URL就知道要什么；
看HTTP method就知道干什么；
看HTTP status code就知道结果如何。

这些总该懂了吧。你要是还不懂，那就没办法了，我们就只能往下看了，然后再回来看上面几句话，保你秒懂。

RESTful 与 RESTful API

REST 是一组架构约束条件和原则，而满足这些约束条件和原则的应用程序或设计就是 RESTful。基于RESTful设计的API，我们就叫做RESTful API。

REST 是面向资源的，这个概念非常重要，而资源是通过 URI 进行暴露。在RESTful架构中，每个URI代表一种资源，所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表名对应，一般来说，数据库中的表都是同种记录的”集合”，所以API中的名词也应该使用复数。

换句话说，URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关，操作是通过 HTTP动词来体现，所以REST 通过 URI 暴露资源时，会强调不要在 URI 中出现动词。

比如：左边是错误的设计，而右边是正确的

GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗 
GET /rest/api/addDogs --> POST /rest/api/dogs 添加一个小狗狗 
GET /rest/api/editDogs/:dog_id --> PUT /rest/api/dogs/:dog_id 修改一个小狗狗 
GET /rest/api/deleteDogs/:dog_id --> DELETE /rest/api/dogs/:dog_id 删除一个小狗狗

REST API 是基于 HTTP的，所以你的API应该去使用 HTTP的一些标准。这样所有的HTTP客户端（如浏览器）才能够直接理解你的API（当然还有其他好处，如利于缓存等等）。REST 实际上也非常强调应该利用好 HTTP本来就有的特征，而不是只把 HTTP当成一个传输层这么简单了。

HTTP动词：

GET     获取一个资源 
POST    添加一个资源 
PUT     修改一个资源 
DELETE  删除一个资源

实际上，这四个动词实际上就对应着增删改查四个操作，这就利用了HTTP动词来表示对资源的操作。

HTTP状态码：

200 OK 
400 Bad Request 
500 Internal Server Error

在 APP 与 API 的交互当中，其结果无非就三种状态：

所有事情都按预期正确执行完毕 - 成功
APP 发生了一些错误 – 客户端错误
API 发生了一些错误 – 服务器端错误

这三种状态与上面的状态码是一一对应的。

HTTP报头：

Authorization 认证报头 
Cache-Control 缓存报头 
Cnotent-Type  消息体类型报头 
......

报头还有很多，不一一列举。HTTP报头是描述HTTP请求或响应的元数据，它的作用是客户端与服务器端进行相互通信时，告诉对方应该如何处理本次请求。