API
生命周期
API 围绕单一、持续演进的 GraphQL 端点构建。这种架构确保新功能和性能改进能够持续交付,而无需在 API 版本之间进行迁移。
本页概述了 API 中不同的稳定性级别、稳定 API 的稳定性保证、变更的类型(破坏性与非破坏性),以及弃用的管理方式。有关当前处于预览阶段的功能,请参阅实验性功能。
功能生命周期
每个功能都处于三个稳定性级别之一:alpha、beta 或稳定。大多数功能会按顺序经历这些级别,而稳定功能只能通过弃用流程来停用。
稳定 API
稳定功能是 API 中可用于生产环境的核心部分。变更分为两类:非破坏性变更和破坏性变更。
非破坏性变更
向后兼容的新增内容,不会影响现有集成。这些变更会持续发布,无需提前通知,也无需弃用。
非破坏性变更包括:
- 添加新的查询、mutation 或 subscription。
- 为现有操作添加新的可选输入参数。
- 添加带有默认值的新参数,且该默认值保留现有行为。
- 为现有操作的输出添加新字段。
- 将必填输入参数更改为可选。
- 为现有枚举类型添加新值。
为非破坏性变更做好准备
非破坏性变更仍可能影响做出严格假设的客户端。为保持集成的弹性:
- 避免严格的对象反序列化,否则当负载中出现额外属性时会失败。
- GraphQL
enum类型不是穷尽的,并会随时间扩展。请始终在客户端逻辑中实现回退的默认分支。 - 检查错误的
extensions.exception.code值,而不是匹配人类可读的错误字符串。
破坏性变更和弃用
破坏性变更可能会破坏正在运行的现有集成。因此,任何破坏性变更都必须先经过 12 个月的弃用流程。
破坏性变更包括:
- 移除或重命名现有的查询、mutation、subscription、字段或输入参数。
- 移除或重命名枚举值。
- 更改现有字段或输入参数的数据类型。
- 添加新的必填输入参数。
- 将可选输入参数更改为必填。
- 更改现有字段的业务逻辑或行为。
- 将输出字段从非空 (!) 更改为可为空。
- 更改输入参数或字段的默认值。
- 更改分页默认值、最大页面大小或已记录的排序顺序。
弃用时间线
当破坏性变更需要移除或替换稳定功能时,它会遵循严格的三阶段时间线:
- 弃用公告该功能在 GraphQL schema 中被标记为
@deprecated指令。如适用,会提供迁移路径。弃用及相应的移除日期会同时通过三个监控渠道公布。 - 活跃通知期(第 1–12 个月)已弃用的功能仍可完全正常运行。如果提供了迁移路径,集成方应在这 12 个月内更新其应用并采用新字段。
- 永久移除到达移除日期时,该功能将被永久移除。此后任何使用该功能的请求都将因 schema 验证失败而返回 GraphQL 错误。
跟踪弃用
通过三个渠道识别并跟踪即将停用的功能:
- 在您的 schema 工具中检查
@deprecated(reason: "...")指令。 - 在 API 的旧版部分或弃用门户中查看停用日期和迁移指南。
- 监控 API 响应中直接返回的
DEPRECATED_FEATURE警告。
响应示例
此内容是否有帮助?