大多数应用都是使用某种形式的客户端 SDK 或 API 网址编写的。客户端 SDK 和 API 网址会绑定到特定的 Looker API 版本。即使 Looker 对新 API 版本进行更改，您的应用也将继续运行。在您选择升级客户端 SDK（或修改 API 网址）以使用新的 Looker API 版本之前，您的应用不会受到其他 API 版本变更的影响。
Looker 如何更改 API
Looker API 的架构旨在为 Looker API 端点提供稳定性，从而为您的应用提供稳定性。
随着我们向 Looker 中添加更多功能和特性，我们也会更新 Looker REST API，以便访问或管理这些新功能。对于每个 Looker 版本，我们都会向当前版本的 Looker API 添加新的 API 函数、参数和响应类型属性。在大多数情况下，API 中的新增内容不是破坏性更改，因此我们可以保留现有版本的 API，而不会影响基于该 API 构建的任何现有应用代码。您现有的应用代码可能只是不了解后续 Looker 版本中显示的新函数、参数或功能。
对于会破坏现有应用代码的 API 更改，我们会将这些破坏性更改打包到新的 API 版本中。这意味着，旧版 API 版本将继续按原样运行，而新版 API 版本则会在旧版 API 版本旁边运行，并包含相应更改和更新。多个 API 版本可以在单个 Looker 实例中并存，以便您选择何时升级到新 API 版本。您为调用旧端点而构建的现有代码将继续调用旧端点。新代码应在最新的 API 版本级别中调用新版本的端点。
唯一的例外情况是严重的安全问题。如果我们发现与 API 的特定部分相关的严重安全问题，我们会尽快采取一切必要措施来缓解该安全问题，这可能包括在有适当解决方案之前停用易受攻击的功能）。
如果我们需要弃用某项功能、方法或属性，以便改用更好的实现或解决方案，通常会将当前 API 保持不变，但会将关联的 API 端点标记为“已废弃”，以指示您应在应用代码中弃用该端点。
API 的破坏性更改和增补性更改
破坏性更改是指删除或重命名 API 端点的现有工件。可能包括：
- 更改或删除参数名称或类型
- 添加新的必需参数
- 更改基本网址
- 更改或删除响应中的现有媒体资源
另一方面，稳定端点可以进行累加更改。其中可能包括：
- 新的可选参数
- 响应中新增的属性（我们不认为这会破坏，因为我们假定您的代码会忽略响应中的未知属性，这是 REST API 社区的常见做法）
如果稳定的 Looker API 端点需要进行重大更改才能采用新架构或功能，这些更改通常会添加到新端点并打包到新 API 版本中，以便现有 API 端点保持不变。
API 端点的标志
大多数 API 端点都被视为稳定，这意味着它们不应发生变化。除非在极端情况下（例如修复安全问题），否则 Looker 不会向稳定端点发布破坏性更改。
其他 API 端点可能会被标记为 Beta 版或已废弃：
- Beta 版端点目前还在积极开发中，将来可能会发生变化。它们无法免受破坏性更改的影响。使用 Beta 版端点时，请考虑对 Looker API 所做的更改是否会对您的应用或开发周期造成特别大的干扰。如果您打算使用 Beta 版端点，请阅读 Looker 的版本说明，以了解任何变更。
- 已废弃的端点是指目前仍受支持且仍可使用的端点，但将在未来的版本中被删除。使用已废弃端点的旧代码应更新为停止使用已废弃端点。当 Looker 的未来版本移除对该端点的支持时，仍在使用该端点的所有代码都会失效。在大多数情况下，已废弃的端点将被改进后的功能取代。如果您发现应用使用了已废弃的函数或属性，最好尽快重构代码以替换已废弃的元素。
API Explorer 和 4.0 API 参考文档中会将 Beta 版端点和已废弃的端点标记为 Beta 版和已废弃。未标记的端点被视为稳定。
迁移到新 API 版本
当您选择将客户端 SDK 或 API 网址升级到新 API 版本时，需要检查应用代码，看看您是否依赖于新 API 版本中已更改的内容。请务必执行以下操作：
- 在应用代码中搜索更新后的函数、值和属性名称。
- 验证您的应用代码是否支持类型的任何更改（例如将整数转换为字符串）。
- 审核代码（请参阅“审核代码”部分）。
审核您的代码
对于某些语言，API 中的破坏性更改可能会在构建时以编译错误的形式被发现：
- 如果您的应用是用编译型强类型语言编写的，那么由于编译类型检查和编译器错误消息，新 API 版本中与现有代码不一致的参数或响应类型的结构更改应该很明显。
- 如果您的应用是使用松散类型的动态语言（例如 JavaScript、Ruby 和 Python）编写的，则可能更难找到受新 API 版本中破坏性更改影响的应用部分。这类语言可能需要运行时单元测试来查找与类型更改相关的任何问题。
在所有情况下，最佳实践是使用单元测试来运行应用代码，包括对 Looker API 的调用（而非模拟调用）。