8 个常见 API 错误示例和用例

应用程序编程接口（API）是一种软件接口，充当连接计算机和计算机程序的媒介。 API 变得越来越有价值，它们产生了许多公司收入的很大一部分，包括 Google、Amazon 和 Salesforce 等公司。如今，API 已采用了有用的功能，这些功能只会增加其价值 – 例如，现代 API 遵循开发人员友好的标准（例如 HTTP），并为其设计、构建和版本拥有自己的软件开发生命周期 (SDLC) 。

创建 API 可以快速而简单，但是创建安全的 API 需要更多的工作和精确度。 API 开发人员也是人，因此可能会发生错误，这最终会影响用户体验。以下是一些可能出现的常见 API 错误：

1.使用http://代替https://

尽管有时 API 同时支持 HTTP 和 HTTPS，但缺少一个“s”可能会导致开发人员出错。例如，某些 API 将 HTTP 流量重定向到其对应的 HTTPS，但并非所有框架都会配置为遵循 302 状态代码。 API 也可能会停止支持 HTTP，虽然好的 API 提供商会提前让用户知道，但及时了解任何变化也很重要。

  2. 过时的缓存

缓存对于互联网和用户体验至关重要。通过将数据保存到公共文件中，用户可以一次又一次地访问相同的资源，而不会导致服务器过载。缓存通常是一种很好的做法，但实施不当可能会成为障碍和麻烦。

例如，假设有一个电子商务 API 系统，它被设置为频繁缓存，以便更新库存并减少繁忙周期期间的服务器负载。如果 API 正在进行大促销，则会将大量商品添加到列表端点。然而，问题在于在缓存列表端点时如何呈现数据。如果数据通过动态 Web 前端以实时形式呈现，客户可以看到新数据，但实施不当的缓存可能会导致出现可点击的项目、图片，甚至描述，所有这些都会导致 404 页面。点击。这只是因为该端点的分辨率尚未缓存。
在这种情况下，开发人员像消费者一样测试 API 非常重要。这将使他们能够更加谨慎和关注地处理代码，以增强用户体验并最大限度地减少任何缓存错误。

3.意外错误码

每当代码中出现不一致时，API 错误消息都会为开发人员指明正确的方向。然而，有时会出现意外的错误代码，并且缺乏有关错误原因的足够信息，导致开发人员不得不自行解决问题。

对于 API 提供商来说，简化开发流程非常重要，通信平台 Twilio 就是一个例子。 Twilio 实现在错误消息中提供链接，为开发人员指明正确的方向，以解决代码中可能出现的任何错误。通过保持简洁并为开发人员提供更多有用的信息，可以快速解决任何错误。

4. 使用错误的HTTP方法
开发人员使用错误的 HTTP 方法是很常见的。通常，这可以归咎于糟糕的文档，但如果开发人员不专心，工具也可能导致障碍。例如，当开发人员想要创建带有请求正文的 GET 请求时，最好使用 -d 选项发出curl 请求，而不是使用`-XGET`标志，该标志将自动默认为 POST并包括 `Content-Type: application/x-www-form-urlencoded` 标头。

其他时候，我们可能会陷入过去的假设并使用不正确的方法。例如，Runscope API 在创建新资源（例如测试步骤或环境）时使用 POST，在修改它们时使用 PUT。但是Stripe的API在创建和更新对象时使用POST方法。
无论开发人员选择哪种方法，重要的是在整个 API 中保持一致，并确保拥有正确且最新的文档，这样用户就不会遇到此错误。

5. 发送无效的授权凭证

如果请求失败，开发人员必须确保他们在代码中使用正确的单词，这一点很重要。例如，实现 OAuth 2 的 API 通常要求开发人员为每个请求包含一个“Authorization”标头。然而，人们常常将其与“身份验证”混淆。
使用 HTTP 基本身份验证时，密切注意标头值的语法和语法也很重要。形式如下：

授权：基本base64_encode(用户名:密码)

常见错误包括忘记“Basic”（注意引号前的空格）前缀、未对用户名和密码进行编码或忘记它们之间的冒号。如果 API 提供商只需要没有密码的用户名（例如 Stripe，其中 API 密钥就是用户名），则即使没有密码，也需要用户名后面的冒号。

6. 未指定 Content-Type 或 Accept 标头

Accept 和 Content-Type 标头协商将在客户端和服务器之间发送或接收的信息类型。某些 API 将接受不包含任何这些标头且仅默认为通用格式的请求。

但是，如果您不明确 Accept 标头值，其他 API 可能会返回 403 错误，并且会要求您在请求中包含这些标头。这会提醒服务器客户端正在发送什么信息，以及应该接收什么格式的信息。

7. 出现错误时 API 返回无效内容类型

对于 API 提供商，某些框架和 Web 服务器默认为 HTML。因此，如果开发人员正在创建一个不需要返回 HTML 的 API，那么检查默认的错误响应非常重要。
另一个需要警惕的方面是位于 API 前面的路由网格或负载均衡器。例如，如果您的 API 前面有一个 nginx 实例，并且遇到请求超时或其他错误，则它可能会在您的 API 实例有机会接收有关正在发生的情况的信息之前返回 HTML 错误。

8、团队沟通失败

在任何公司中，团队之间无法沟通都可能导致一系列错误和损害控制。例如，如果开发团队没有将类型更改通知支持团队，那么支持团队就会散布错误信息，从而损害用户体验。同样，如果 UX 团队不向开发团队传达界面更改，则可能会导致网站功能中断，并且 API 基本上无法访问。
解决这种情况的方法很简单——沟通和团队努力。在蓝图阶段制定计划时，最好遵守该计划并将所做的每一次修订通知相应的团队。

这些是 API 中可能出现的一些最常见的错误。它们可能会被忽视，并导致花费更多时间进行故障排除和调试。但借助上述指导，再加上更高水平的意识和对细节的关注，这些错误是可以避免的。

原文链接：https://rapidapi.com/blog/8-common-api-error-examples-and-use-cases/