大多數應用程式都是使用某種形式的用戶端 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 一同運作，並提供變更和更新。單一 Looker 例項中可以並存多個 API 版本，讓您選擇何時升級至新版 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"]],["上次更新時間：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)."]]
