【玩转 Postman 接口测试与开发2_002】第一章 API 相关术语及类型概述 + 1.1 何谓 API + 1.2 API 的调用类型

《API Testing and Development with Postman》最新第二版封面

第一章 API 相关术语及类型

学习新知识有点像从船舷上跌落的感觉：什么都在动，而您只能勉强把头露出水面。好不容易才开始觉得自己弄明白了一些东西的原理，结果冷不丁冒出一个新知识点来，整个世界又开始摇摇欲坠……待到有了坚实的依靠，您才终于有机会环顾四周，弄清自己的方向。在探索新知识的过程中，整个世界这才变得阳光正好，微风不燥。

本章内容将为您打下坚实的基础。与几乎所有专业一样，API 测试与开发也有一套专属术语。使用 API 时，很多术语都是有专门的含义。本书会用到其中一部分术语，并希望我们在这些术语的含义上能够达成共识。

我会尽量使用标准定义。可即便如此，一些术语本就没有普遍公认的定义，对于这些术语，我会在本书中分享我的一些浅见。还望切记：当您在网上浏览文章或收听节目，甚至只是与内部组员交流时，别人对这些术语的理解和用法可能和我略有不同。

本书不是一部字典，所以我不打算只列出一堆术语及其定义。那样会很无趣，而且也没有什么指导意义。相反，我会花一些工夫介绍 API 的基本概念以及测试相关的理论知识，其中一些重要的术语将贯穿全书始终。

本章将涵盖以下主要内容：

• 何谓 API？
• API 的调用类型
• Postman 的安装
• API 请求的结构
• API 测试相关注意事项
• 不同种类的 API

学完本章，您将能够使用 Postman 创建 API 请求，并熟练掌握基本的 API 术语。同时还将有机会完成一个小练习，助您巩固所学，以便在日常工作中学以致用。

1.1 何谓 API？ What is an API?

在美国国家航空航天局（即 NASA）1969 年出版的一份名为《计算机程序摘要》（Computer Program Abstracts）的出版物中，有一则关于 IBM 出售的实时显示控制程序的广告摘要是这么说的：只要 310 美元！外加 36 美元附赠精美文档。广告上还说，它是专为操作员级应用程序（operator-application）设计的编程接口，换句话说，它就是一个 API。

应用程序编程接口（API） 的历史可以与计算机代码的发展史一样悠久。从概念上讲，它只是两种不同的代码（或者是人类与某些代码）之间彼此交互的一种方式。我们说一个类（class）拥有一套 API，是说它具备了某些公共方法，其他代码可以调用；而一个脚本（script）拥有一套 API，则表示它能接受特定类型的输入（input）；甚至是一个计算机上的驱动程序也能拥有一套 API，只要规定其他程序按照特定的某种方式进行调用即可。

然而，随着互联网的发展，API 一词的关注范围也在逐渐缩小。现在，当人们谈论 API 时，几乎都是在谈论 Web API —— 本书也将在这样的语境中展开相关介绍。Web API 将两个事物间的接口的概念，推广应用到互联网所构建的“客户端/服务器”关系中。在一个典型的 Web API 模型中，客户端在接口的这一边发送请求；而服务端（一台或多台服务器）则在接口的另一边响应该请求。

随着时间的推移，互联网不断发展演化，Web API 也随之不断演进。许多早期的 Web API 都是为企业量身定制的，对于接口双方如何交互有着严格的规定。一种名为 简单对象访问协议（Simple Object Access Protocol，即 SOAP） 的 API 应运而生。然而，就在本世纪初，互联网开始转为以消费者为基础，一些电子商务网站（如 eBay 和亚马逊）开始发布更加公开与灵活的 API。随后，Twitter、Facebook 等许多知名社交媒体网站也纷纷发布各自的 API，其中大部分都是基于一种名为 表现层状态转换（Representational State Transfer，即 REST） 的模式构建而成的。

这种方法比 SOAP 更为灵活，可以直接在互联网的基础协议上进行构建。

但互联网仍在不断变化，随着移动端应用与网站的普及，API 的重要性也日渐凸显。一些公司面临着在移动设备上传输大量数据的挑战，为此 Facebook 专门创建了一种名为 GraphQL 的 API。这种类型的 API 定义了一种查询语言（query language），有助于减少传输的数据量，同时也为 API 引入了一种稍显严格的结构。这些不同类型的 API 在某些情况下都能很好地发挥作用，本章将在最后一节进行介绍。不过，在详细介绍每种类型的 API 之前，首先要了解支撑所有 Web API 调用的一些基本概念。

1.2 API 的调用类型 Types of API calls

一些 API 调用可以更改服务端上的内容，而另一些则只返回数据，不对内容做任何修改。API 调用可能会以不同的方式影响数据，这些不同的方式可以通过术语 安全（safe） 和 幂等（idempotent） 来进行描述。这些术语听起来让人有些望而生畏，为了更好地理解它们，不妨来看一个通俗易懂的例子：乐高积木。

试想有这么一张桌子，上面放着几块乐高积木，而我就坐在桌子旁边。我代表一个 API，桌子则代表服务端，乐高积木则代表一些目标对象（objects）。与乐高积木的所有互动都必须通过我来促成。在下面的示意图中，乐高积木代表服务端上的对象，我代表 API（应用程序接口），而您则代表客户端：

图 1.1：通过 API 连接服务端和客户端示意图

在上述假想关系中，您代表客户端，言下之意您可以让我用乐高来完成某些事。比如让我告诉您最上面的乐高积木有多大；我回答说，它的大小是 1。这就是 安全的（safe） API 请求与响应的示例。安全请求 是指不会更改服务端上 任何内容 的请求。您只问我请求了服务端中正在发生的事物的信息，因此并没有改变服务端本身的任何内容。

不过，其他类型的 API 调用就不好说了。试想：您给了我一块大小为 2 的积木，让我用那块积木把顶端的积木替换掉。我照做了，这样就改变了服务端的状态。如下图所示，积木堆现在由一块大小为 3 的积木和两块大小为 2 的积木组成：

图 1.2：新服务端状态示意图

由于服务端有变动，因此该请求不是一个安全的请求。但是，如果您再给我一块大小为 2 的积木，并再次要求我替换掉最上面的积木，这时服务端就不会有任何变化。那堆积木仍然是由一块大小为 3 的积木和两块大小为 2 的积木组成。这就是 幂等（idempotent） 调用的示例。无论调用多少次都返回相同结果的 API 调用，我们就说它是 幂等的（idempotent）。

接着再想象另一种调用方式：您给我一块积木，让我把它加到积木堆的顶端。我又照做了，此时积木堆便由四块积木组成。这次显然不是安全调用，因为服务端已经改变了，但它是幂等的吗？

答案是否定的，但请花点时间思考一下，确保您真正理解了该调用不是幂等调用的原因。

如果很难理解，那么不妨想想如果重复同样的请求会发生什么：再给我一块积木，让我把它加到积木顶端。第二次这样做，积木还是我第一次添加后的样子吗？当然不是！此时共有五块积木，并且每让我加一次，积木堆会变动一次。幂等调用仅在第一次执行时改变事物的状态，后续调用都不会做任何改变。而刚才的调用每次都会改变一些东西，因此它不是幂等调用。

安全性（Safety）和幂等性（idempotency）是需要重点掌握的核心概念，尤其是在做 API 测试的时候。如果测试的是安全调用，则可以并行地运行测试，不必担心它们会相互干扰；但如果测试的是不安全的、或非幂等的调用，那么在运行测试的类型和时间上可能需要更加谨慎一些。

除了安全和幂等，我们还需要学习一些更重要的术语，并对 API 请求的结构做进一步深入了解。不过要是手里有看得见摸得着的东西，操作起来就会轻松得多。所以下一节，我们将稍作停顿，先完成 Postman 的安装并发送我们的第一个请求。