Luna Tech | RESTful API 入门

October 14, 2020 字数 2239 5 min


0. 前言

上一篇文章讲了 HTTP 的一些基本知识,今天我们来聊聊 RESTful API 这个概念。

Luna Tech | HTTP 入门

RESTful API 是什么?

RESTful API,顾名思义,包含三个部分:

  1. API
  2. REST
  3. RESTful - 形容词,像 REST 一样的

我们下面就来逐一讲解一下。


1. API 是什么?

API 是 Application Programming Interface 的简称,中文名:应用程序接口。

如何理解接口呢?简单来说,接口 = 两个程序之间的沟通方式。

A 程序想要给 B 程序发送信息,A 程序就需要通过 B 程序的接口来传输数据。

B 程序从接口接受到信息之后,进行内部的消化处理,可以返回一个 A 程序期待的结果。

这里的重点是:B 程序需要告诉 A 程序,我能接受的信息格式是怎么样的,我会返回什么样的东西给你。

这么一来,A 就知道应该在什么情况下可以找 B,以及需要的时候要如何和 B 沟通。


2. REST & RESTful

REST 全称为 REpresentational State Transfer,中文:表现层状态转换。

REST 是一种软件的架构方式(Software Architectural Style),它定义了一系列的规则,这些规则是用来创建 Web Service(网络服务)的。

符合 REST 规则的 Web Service,就叫做 RESTful Web Service。

听到这里,你可能要问,Web Service 跟 API 又有什么区别啊?我们讲的不是 RESTful API 吗?怎么又来了个 RESTful Web Service?

事实上,Web Service 就是帮助两个程序通过网络沟通的服务,也可以理解为网络版的 API,总之就是为了让程序之间能互相听懂对方在讲什么,达到传输信息,获取信息的目的。

RESTful Web Service = RESTful API

那……REST 有什么规则呢?

注意: REST 架构跟 HTTP 协议一样,也用到了 Client-Server 这个架构。 服务器是提供资源的,客户端是要找服务器拿资源的。

  1. 统一接口(Uniform interface):所有想要跟我说话的人都必须通过同一个接口,我对大家一视同仁;
  2. 客户端服务器分离(Client-Server Separation):客户端和服务器是完全独立行动的,它们唯一的互动方式就是通过 API 聊天,客户端发出请求(request),服务器进行回复(response);
  3. 无状态(Statelessness):服务器不认识客户端,每次聊天(request)都是一个独立的对话,所以客户端每次来聊天的时候必须把所有必要的信息都带着;
  4. 资源可缓存(Cacheable resources):服务器的回复必须明确表明“我这个回复你可以存着/不能存着”,假如服务器说可以存,那么这个回复必须要有版本号 Version Number,这样客户端就不需要一直追着服务器要相同的回复了(减少重复沟通);
  5. 系统分层(Layered System):在服务器和客户端之间可能会有多个中间层(传话的),但是传话的人不能擅自更改客户端的请求,也不能修改服务器的回复,传话的必须要保持公正公平;
  6. 根据需要编程(Code on demand):这条不是必须要符合。在必要的情况下,服务器的回复可以带着可执行的代码(比如 HTML 里面带一段 JavaScript 代码),客户端可以执行服务器带来的代码。

满足 REST 6 大定义的前 5 条的 Web Service,都可以算是 RESTful API。

等等……资源是什么?

资源可以简单理解为数据。

比如你打开一个网页,打开一个图片,听一首歌,这些都是数据。

在 REST 里面,每个资源都是用一个唯一的名称来表示的(URI - Uniform Resource Identifiers),通过 URI 就可以找到你想要的资源。

资源/数据的表现形式是多种多样的,比如图片可以有 png,jpeg;歌曲则是 mp3、wmv 等。

REST 的全称,Representational State Transfer,里面的 Representational,指的就是资源的表现形式。

State Transfer 一词体现了资源的可变性,我们之前说到 Cacheable 的时候,资源是可以携带版本号,被客户端缓存的。客户端缓存的这个资源,就是服务器传来的 State,而 State 是灵活可变的。服务器只负责传输资源的每个状态,不需要考虑资源之前和之后的状态(活在当下的服务器啊~~)。

URI 又是什么??跟 URL 有点像啊……

URI 是 Uniform Resource Identifiers 的简称,URI 包含了 URL + URN。

URL 全称是 Uniform Resource Locator,中文:网址。

URL 是网络的重要组成概念之一,URI 是统一资源标识符,URL 是一种特殊的 URI;URI 只是给了资源一个身份,而 URL 还可以让我们通过网址直接获取资源。

URL 这里就不具体展开啦~ Ref: URI 与 URL 的区别

https://danielmiessler.com/study/difference-between-uri-url/
https://danielmiessler.com/study/difference-between-uri-url/

3. 关键概念

希望你看到这里还没有晕掉~我们来整理一遍 RESTful API 的关键概念吧。

下面这张图简要解释了这些概念之间的关系,从这张图里,我们可以发现一个很有趣的事实,那就是:

我们之前讲的 HTTP 这个协议其实跟 RESTful API 没有任何关系;一个不用 HTTP 协议的,满足 REST 规定的 Web Service,依然是一个 RESTful API。

RESTful API
RESTful API

4. RESTful API 常见问题

1. RESTful API 和 JSON 的关系

有人会问,RESTful API 是不是都用 JSON 格式交换啊?

关于这个问题,我们首先要回到 REST 的架构定义,REST 并没有把数据交换的格式限制为 JSON,所以我们也可以在 RESTful API 里面用 HTML、XML、plain text 来进行数据交换。

2. RESTful API 跟 HTTP 真的没关系吗?

虽然 HTTP 和 RESTful API 不存在绑定的关系,但是绝大多数的 RESTful API 都是通过 HTTP 协议传输的。

巧的是,HTTP 协议也是活在当下的(stateless),每次请求都是独立的,于是这两个性情相投的小伙伴一拍即合。

99% 的情况下,人们提到 RESTful API,传输协议就默认为 HTTP,也就是基于 HTTP 传输的 RESTful API。


5. 结语

今天这篇文章主要讲了:

  1. API 是什么 - 接口:两个程序之间的沟通方式
  2. REST 是什么 - 一种软件的架构方式,定义了 Web Service 的规则
  3. Web Service - 网络版的 API,让程序联网沟通
  4. REST 的 6 大规则 - 满足前 5 个的 Web Service 就算 RESTful API
  5. RESTful Web Service = RESTful API
  6. REST 资源 - 用 URI 来标识
  7. URI 和 URL 的区别 - URI 包含 URL
  8. RESTful API 不一定要用 JSON 进行数据交换
  9. RESTful API 和 HTTP 的关系 - 本质上毫无关联,但实际上大部分 RESTful API 都基于 HTTP 协议传输。

希望对大家有所帮助~


Support Luna