本文档介绍使用 Compute Engine API 时建议的最佳做法，适用于已熟悉该 API 的用户。如果您是新手，请了解前提条件以及如何使用 Compute Engine API。
遵循这些最佳实践可帮助您节省时间、防止错误并缓解速率配额的影响。
使用客户端库
建议使用客户端库以编程方式访问 Compute Engine API。客户端库提供允许您通过常用编程语言访问 API 的代码，帮助您节省时间并提升代码性能。
详细了解 Compute Engine 客户端库和客户端库最佳实践。
使用 Cloud 控制台生成 REST 请求
创建资源时，使用 Google Cloud 控制台中的资源创建页面或详情页面生成 REST 请求。使用生成的 REST 请求可以节省时间并有助于防止语法错误。
了解如何生成 REST 请求。
等待操作完成
切勿假设操作（任何更改资源的 API 请求）已完成或成功。而是改为对 Operation 资源使用 wait 方法来验证操作是否已完成。（您无需验证不会修改资源的请求，例如使用 GET HTTP 动词的读取请求，因为 API 响应已指示该请求是否成功。因此，Compute Engine API 不会为这些请求返回 Operation 资源。）
成功发起 API 请求后，它会返回 HTTP 200 状态代码。虽然收到 200 表示服务器已成功收到您的 API 请求，但此状态代码并不表明请求的操作是否成功完成。例如，您会收到 200，但操作可能尚未完成或操作可能已失败。
任何针对长时间运行的操作的创建、更新或删除请求都会返回 Operation 资源，该资源会捕获该请求的状态。当 Operation 资源的 status 字段为 DONE 时，表示操作已完成。如需检查状态，请使用与返回的 Operation 资源的范围匹配的 wait 方法：
- 对于可用区操作，请使用
zoneOperations.wait。 - 对于区域操作，请使用
regionOperations.wait。 - 对于全球操作，请使用
globalOperations.wait。
当操作完成或请求已接近 2 分钟的时限时，wait 方法会返回。使用 wait 方法时，请避免短轮询，即客户端不断向服务器发出请求而不等待响应的情况。在具有指数退避算法的重试循环中使用 wait 方法检查请求的状态，而不是对 Operation 资源使用带有短轮询的 get 方法，这有助于保持您的速率配额并减少延迟时间。
如需详细了解如何使用 wait 方法及其示例，请参阅处理 API 响应。
如需检查所请求操作的状态，请参阅检查操作状态。
在等待操作完成时，请考虑操作最短保留期限，因为已完成的操作可能会在此期限过后从数据库中移除。
将列出的结果分页
使用 list 方法（例如 *.list 方法、*.aggregatedList 方法或返回列表的任何其他方法）时，请尽可能对结果进行分页以确保您读取整个响应。如果未分页，则您最多只能接收由 maxResults 查询参数确定的前 500 个元素。
如需详细了解 Google Cloud 上的分页，请参阅列表分页。如需了解具体详情和示例，请参阅要使用的 list 方法的参考文档，例如 instances.list。
您还可以使用 Cloud 客户端库来处理分页。
使用客户端列表过滤条件来避免配额错误
当您将过滤条件与 *.list 或 *.aggregatedList 方法搭配使用时，如果请求中已过滤的资源超过 1 万个，则会产生额外的配额费用。如需了解详情，请参阅速率配额中的 filtered_list_cost_overhead。
如果您的项目超出此速率配额，您会收到 403 错误和原因 rateLimitExceeded。为避免此错误，请对列表请求使用客户端过滤条件。
依赖于错误代码，而非错误消息
Google API 必须使用 google.rpc.Code 定义的规范错误代码，而错误消息随时可能不事先告知就发生变化。错误消息通常旨在供开发者读取，而不是程序。
详细了解 API 错误。
最大限度地减少客户端重试次数以保留速率配额
最大限度地减少项目的客户端重试次数，以防止出现 rateLimitExceeded 错误，并最大限度地提高速率配额的利用率。以下做法可帮助您维持项目的速率配额：
- 避免短轮询。
- 谨慎并选择性地使用爆发。
- 始终使用指数退避算法在重试循环中进行调用。
- 使用客户端速率限制器。
- 将应用拆分到多个项目之间。
避免短轮询
避免短轮询，即客户端不断向服务器发出请求而不等待响应的情况。进行短轮询会导致更难以捕获计入配额的错误请求，即使这些请求未返回有用的数据也是如此。
您应该等待操作完成，而不是进行短轮询。
请谨慎并选择性地使用爆发
请谨慎并选择性地使用爆发。爆发是允许特定客户端在短时间内发出许多 API 请求的行为。爆发通常是为了响应异常情况，例如应用需要处理的流量比平常多的情况。爆发通过速率配额快速消耗，因此请确保仅在必要时使用。
如果需要爆发，请尽可能使用专用批处理 API，例如批量实例 API 或代管式实例组。
详细了解批处理请求。
始终使用指数退避算法在重试循环中进行调用
使用指数退避算法，在请求超时或达到速率配额时逐步递增发送请求的间隔。
任何重试循环都应具有指数退避算法，以确保频繁重试不会导致应用过载或超出速率配额。否则，可能会对同一项目中的所有其他系统造成负面影响。
如果您需要为因达到速率配额而失败的操作创建重试循环，则指数退避算法策略应在重试之间留出足够的时间，以便配额分桶重新填充（通常每分钟一次）。
或者，如果您需要在等待操作超时时使用重试循环，则指数退避算法策略的间隔时间上限不应超过操作的最短保留期限。否则，您可能会收到操作 Not Found 错误。
如需查看实现指数退避算法的示例，请参阅 Identity and Access Management API 的指数退避算法。
使用客户端速率限制器
使用客户端速率限制器。客户端速率限制器会设置一个人为限制，使相关客户端只能使用一定数量的配额，从而防止任何一个客户端耗尽所有配额。
将应用拆分到多个项目之间
将应用拆分到多个项目之间有助于最大限度地减少配额桶的请求数量。由于配额按项目级层应用，因此您可以拆分应用，以便每个应用都有自己专用的配额桶。
核对清单摘要
以下核对清单总结了使用 Compute Engine API 的最佳实践。