大多数应用都是使用某种形式的客户端 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 端点标记为“已废弃”，以指示您应在应用代码中弃用该端点。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-07-31。"],[],[],null,["# Looker API versioning\n\n| **Note:** As of Looker 22.4, the [Looker API 4.0 is generally available](/looker/docs/api-4-ga). In Looker 23.18, the [Looker API 3.1 has been removed](/looker/docs/api-3x-deprecation).\n\nMost applications are written using some form of a client SDK, or possibly an API URL. The client SDK and API URLs are bound to a specific Looker API version. Your application will continue to function even as Looker makes changes to new API versions. Your application won't be affected by changes in other API versions until you choose to upgrade your client SDK (or modify the API URL) to use the new Looker API version.\n\nHow Looker makes changes to the API\n-----------------------------------\n\nThe Looker API is architected to provide stability for Looker API endpoints, and therefore stability for your applications.\n\nAs we add more features and capabilities to Looker, we also update the Looker REST API to access or manage those new features. For each Looker release, we add new API functions, parameters, and response type properties to the current version of the Looker API. In most cases, additions to the API are not [breaking changes](#breaking_and_additive_changes), so we can keep the existing version of the API without affecting any existing application code that is built on the API. Your existing application code may simply be unaware of new functions, parameters, or features that appear in subsequent Looker releases.\n\nFor changes to the API that would break existing application code, we bundle those breaking changes into a new API version. This means that the old API version will continue to work the same as before, while a new API version runs alongside it with the changes and updates. Multiple API versions can exist side by side in a single Looker instance so that you can choose when to upgrade to the new API version. Your existing code that was built to call the old endpoint will continue to call the old endpoint. New code should call the new version of the endpoint in the most recent API version level.\n\nOne exception to this is for critical security issues. If we discover a critical security issue related to a particular part of the API, we will do whatever is necessary to mitigate that security issue as soon as possible, which may include disabling the vulnerable functionality until a proper solution is available).\n\nIf we need to retire a feature, function, or property to make way for a better implementation or solution, we normally leave the current API as it is, but mark the associated API endpoints as [\"deprecated\"](/looker/docs/api-versioning#deprecated_api_endpoints) to indicate that you should move away from the endpoint in your application code.\n\n### Breaking and additive changes to the API\n\nA *breaking* change is something that deletes or renames an existing artifact of an API endpoint. It might include:\n\n- Changing or deleting a parameter name or type\n- Adding a new required parameter\n- Changing the base URL\n- Changing or deleting an existing property in a response\n\nAn *additive* change, on the other hand, may be made to [stable](#stable_api_endpoints) endpoints. They might include:\n\n- New, optional parameters\n- New properties in responses (we do not consider this breaking because we assume that your code will ignore unknown properties in responses, which is common practice in the REST API community)\n\nIf a stable Looker API endpoint needs a significant change to move forward with new architecture or functionality, the change is usually added to a new endpoint and bundled into a new API version so that the existing API endpoint remains unchanged.\n\n\nFlags for API endpoints\n-----------------------\n\nMost API endpoints are considered *stable* , meaning they are not expected to change. Looker will not release [breaking changes](#breaking_and_additive_changes) to stable endpoints except in extreme cases, such as to fix a security problem.\n\nOther API endpoints may be flagged as *beta* or *deprecated*:\n\n- **Beta endpoints** are in active development and may change in the future. They are not protected from breaking changes. When using beta endpoints, consider whether a change to the Looker API would be particularly disruptive to your app or development cycle. Please read Looker's [release notes](https://discourse.looker.com/search?q=%23news%3Arelease%20order%3Alatest) if you plan to use a beta endpoint so that you will be aware of any changes.\n- **Deprecated endpoints** are endpoints that are still supported and can still be used at the moment, but will be deleted in a future release. Old code that uses a deprecated endpoint should be updated to stop using the deprecated endpoint. When a future release of Looker removes support for that endpoint, any code that is still using it will break. In most cases, a deprecated endpoint will be replaced by improved functionality. If you find that your application is using a deprecated function or property, it's a good idea to refactor your code to replace the deprecated element as soon as you can.\n\nBeta and deprecated endpoints are marked as such in the [API Explorer](/looker/docs/api-explorer) and in the [4.0 API Reference](/looker/docs/reference/looker-api/latest). Endpoints that aren't marked are considered stable.\n\n\nMigrating to a new API version\n------------------------------\n\nWhen you choose to upgrade your client SDK or API URL to a new API version, you will need to review your application code to see if you're relying on something that has changed with the new API version. Be sure to do the following:\n\n1. Search your application code for the updated function, value, and property names.\n2. Verify that your application code supports any changes in types (such as integer to string).\n3. Audit your code (see the [Auditing your code section](#auditing_your_code)).\n\n### Auditing your code\n\nFor some languages, breaking changes in the API can be discovered at build time as compile errors:\n\n- If your application is written in a compiled, strongly-typed language, structural changes to parameter or response types in a new API version that are at odds with your existing code should be readily apparent thanks to compile type checking and compiler error messages.\n- If your application is written in a loosely-typed dynamic language (such as JavaScript, Ruby, and Python), it may be harder to locate the parts of your application that will be affected by breaking changes in a new API version. These types of languages might require runtime unit tests to find any issues related to changes in types.\n\nIn all cases, the best practice is to have unit tests that exercise your application code, including calls to the Looker API (not mocked calls)."]]
