Dev的自白 #1：被问到“什么是 API？”时我脑子一片空白

Source: Dev.to

问题（比你想象的更糟）

当一个非技术人员问“API 是什么？”时，你可以用服务员或邮递员的比喻来解释。他们会满意。
但当技术人员问时，他们并不想要隐喻。他们已经知道服务器是什么，HTTP 是什么，JSON 是什么。他们想要的是本质的定义——简洁、精准、几乎是哲学式的答案。而这要难得多。

于是，在那尴尬的时刻之后，我回家强迫自己给出一个恰当的答案。以下是我的答案。

我本该说的（技术版）

单句定义（简洁精准）

“API 是一个已定义的接口，规定了一个软件组件如何与另一个组件交互——包括有效请求、预期响应以及底层协议（通常是 HTTP）。”

稍微更技术的答案

“API 是客户端与服务器之间的契约。它说明：‘如果你以这种形式、发送到此 URL、并带有这些头部发送请求，我会以这种形式返回响应——并提供状态码告诉你发生了什么。’”

“啊，对了”类比（仍然技术化）

“把它想象成数据库查询语言，例如 SQL。你发送 SELECT 语句，就会得到结果集。API 的概念相同，只是通过 HTTP——并且不是操作表，而是操作资源（用户、订单、产品）。”

最简答案

“API 是一层抽象，将实现隐藏在一组公开可访问的操作之后。”

那句话本可以让我显得很聪明。但我没有说，我只说了“呃…你懂的”。

为什么技术人员在基本定义上会卡壳

• 我们思考的是使用场景，而不是定义——“API 是我用来获取用户数据的调用”不是定义，而是例子。这是我们大脑存储信息的方式。
• 我们把“它是怎么工作的”与“它是什么”混淆——我可以解释 HTTP 请求循环、JSON 序列化、状态码、限流和身份验证。但那不是 API 本身，那是使用它的方式。
• 我们从未被要求去定义它——在学校，教的是语法，不是定义；在工作中，你只负责构建东西。没人会在冲刺计划会议上说“定义一下 API”。

真正的教训（给开发者，来自开发者）

会构建东西并不等同于会定义它。最优秀的开发者两者都能做到。他们既能谈实现细节，也能在不结巴的情况下抽离到万米高空的定义。

挑战

不查资料，现场用一句话口头定义以下术语：

• HTTP
• JSON
• JWT
• DOM
• TCP

如果做不到，欢迎加入卡壳俱乐部。我们一起练习。

行动号召（你的告白）

现在轮到你了。

哪一个基础技术问题让你在另一位开发者面前卡壳？在评论区留下你的告白。没有评判，只有开发者的诚实。

这是一篇《开发者的自白》。我们都有过这种经历。