0Pricing
System Design Basics for Backend Developers · 课时

API 版本管理与向后兼容

学习如何演进 API 而不破坏现有客户端，包括版本管理方案和兼容性规则。

API 版本管理与向后兼容 是 CoddyKit 上的免费 System Design Basics for Backend Developers 课时。 这是第 4 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 System Design Basics for Backend Developers 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 System Design Basics for Backend Developers 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

Why APIs Must Evolve Carefully

Once an API has clients, you cannot freely change it. Renaming a field or removing an endpoint can break every consumer. Versioning lets you evolve the API while existing clients keep working.

Breaking vs Non-Breaking Changes

Know the difference:

  • Non-breaking: adding a new optional field, adding a new endpoint
  • Breaking: removing a field, renaming a field, changing a type, making an optional field required

Non-breaking changes can ship without a new version; breaking ones cannot.

URI Versioning

The most visible scheme puts the version in the path. It is simple and cache-friendly, and clients can clearly see which version they call.

GET /v1/users/42
GET /v2/users/42

Header Versioning

Alternatively, clients request a version via a header. This keeps URIs clean and treats the version as part of content negotiation.

GET /users/42
Accept: application/vnd.myapp.v2+json

Query Parameter Versioning

A lighter approach uses a query parameter, e.g. ?version=2. It is easy to test in a browser but mixes versioning with regular parameters and can complicate caching.

GET /users/42?version=2

Semantic Versioning

SemVer (MAJOR.MINOR.PATCH) communicates intent:

  • MAJOR: breaking changes
  • MINOR: new backward-compatible features
  • PATCH: backward-compatible fixes

For public HTTP APIs, the MAJOR number usually maps to the URI version.

Additive Change Discipline

The cheapest versioning is not needing a new version. Follow the additive rule: only add, never remove or rename. Clients ignore unknown fields, so adding is safe.

{
  "id": 42,
  "name": "Ada",
  "email": "ada@x.com"
}
// Later, safely add:
{
  "id": 42,
  "name": "Ada",
  "email": "ada@x.com",
  "created_at": "2026-01-01"
}

Deprecation, Not Deletion

When you must retire something, deprecate first. Mark it in docs, send a Deprecation or Sunset header, and give clients a clear timeline before removal.

HTTP/1.1 200 OK
Deprecation: true
Sunset: Wed, 31 Dec 2026 23:59:59 GMT
Link: </v2/users>; rel="successor-version"

Versioning gRPC and GraphQL

It is not just REST. In gRPC, never reuse or renumber protobuf field tags — that breaks the wire format. In GraphQL, the convention is no versions at all: add fields and use the @deprecated directive on old ones.

Supporting Multiple Versions

Running several versions at once has a cost. Strategies include translating old requests to the new internal model, or routing versions to different handlers. Limit how many versions you support and sunset old ones on schedule.

Designing for Change Up Front

Reduce future pain by designing for evolution: prefer objects over bare values so you can add fields, avoid leaking internal enums, and document a clear compatibility contract from day one.

Quick Check

Test your understanding of API versioning.

Recap

You learned how to evolve APIs safely:

  • Distinguish breaking from non-breaking changes
  • URI, header, and query parameter versioning schemes
  • SemVer and the additive-change discipline
  • Deprecate with Sunset headers before deleting
  • gRPC tag stability and GraphQL's deprecation approach

常见问题解答

「API 版本管理与向后兼容」课时是免费的吗？

是的 — 「API 版本管理与向后兼容」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 System Design Basics for Backend Developers 课程的其余内容，请升级到 CoddyKit PRO。 System Design Basics for Backend Developers 课程共包含 4 节课。

「API 版本管理与向后兼容」这节课中我会学到什么？

学习如何演进 API 而不破坏现有客户端，包括版本管理方案和兼容性规则。 你通过在浏览器中直接运行的动手代码来练习 System Design Basics for Backend Developers，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 System Design Basics for Backend Developers 需要有经验吗？

无需任何先前经验。CoddyKit 上的 System Design Basics for Backend Developers 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 4 节课，共 4 节。

「API 版本管理与向后兼容」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 System Design Basics for Backend Developers 课中编写并运行代码吗？

能。每节 System Design Basics for Backend Developers 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. RESTful API 设计原则
  2. GraphQL 与 gRPC
  3. 消息队列与事件驱动
  4. API 版本管理与向后兼容
← 返回 System Design Basics for Backend Developers