技术

API

Application Programming Interface

一段软件与另一段软件对话所经由的约定契约,双方都无需知道对方内部是如何运作的。

最近审阅: 2026-06-02 审阅人Kevin Riedl wiki ↗

API 是一段软件与另一段软件对话的既定方式。它说:这是你可以让我做的事,这是你确切的请求方式,这是你会得到的返回。其全部意义在于,调用方不需要知道工作在内部是如何完成的,只需要知道发送什么、期待什么。你手机上的天气应用并不知道天气服务是如何运作的。它只知道那个 API,发送一个请求,然后得到一份预报。

关键的想法是契约。双方就请求和响应的形态达成一致,只要这份契约成立,任何一方都可以自由更改自己的内部实现。你会听到的两种常见风格是 REST 和 GraphQL。REST 把一切都建模为你通过标准 Web 请求读写的资源,是大多数 Web 和移动后端的默认选择;GraphQL 让调用方在一个请求中精确地索取它想要的字段。两者都只是定义同一份契约的规范化方式。

API 设计是你做出的最持久的决策之一。内部代码你可以在一个周末重构。一个公开 API,别人的软件依赖于它确切的形态,因此更改它会破坏他们的集成,这意味着你往往根本无法在不经历一次痛苦的版本化过程的情况下更改它。一个干净、命名良好、一致的 API 会优雅地老去。一个草率的则会变成你在每一次未来更改中都要缴纳的永久税。我们把 API 设计当作软件开发的一等组成部分,而不是末尾才拼装上去的事后想法。

诚实的看法:大多数"集成简直是噩梦"的抱怨,都可以追溯到一个为了交付一个功能而仓促设计、随后被迫承载十个功能的 API。早早把时间花在契约上。这是你以后最难更改的部分。

// FAQ

常见问题

常见问题

一段软件请求另一段软件做某事的既定方式。它定义了你可以请求什么、如何请求以及你会得到什么返回,因此调用方永远不需要知道另一方内部是如何运作的。应用持续地通过 API 与后端以及彼此对话。
REST 把一切都建模为你通过标准 Web 请求读写的资源,是大多数后端的默认选择。GraphQL 让调用方在单个请求中精确索取它想要的字段。两者都是在调用方与服务之间定义同一类契约的规范化方式。
因为一旦别人的软件依赖于你的 API,更改它就会破坏他们的集成,所以你往往无法在不经历痛苦版本化的情况下更改它。内部代码容易重构。公开的 API 契约是最难逆转的决策之一,所以值得早早做对。