API 中的 HTTP 状态代码的良好做法？

Question

现在我正在使用 laravel 框架构建一个项目。我不是专业人士或其他人，过去我从头开始构建我所有的应用程序，而不使用此类框架。

现在我正在为我网站的某些部分实施 Twitch API。在这样做时，我遇到了 Twitch API 返回 http 错误代码 (40x) 的情况，即使它提供了“有效”响应。现在我正在使用来自 packagist.org 的非常流行的 Twitch API 包。一旦我收到 40x 错误代码，就会抛出一个异常，这会破坏我的应用程序。

原因是响应请求如下所示：

$response = $this->client->send($request);

作为一种解决方法，我将其更改为：

$response = $this->client->send($request, ['http_errors' => false]);

显然我也可以使用of GuzzleHttp\Exception 来处理这些错误。但据我所知，所有这些都必须发生在我通过 composer 下载的包中，这意味着一旦作者发布更新并且我运行 composer update 我的更改将被覆盖并且我的应用程序可能会被破坏，直到我再次修复它。

我猜不是每个人都熟悉 Twitch API。我的问题的一个简单示例是 API 调用，您可以在其中检查特定用户是否正在关注特定频道。当用户不这样做时，响应如下所示：

{ “错误”：“未找到”， "message": "12345 没有跟随 67890", “状态”：404 }

所以这是一个非常好的和有效的响应，很容易处理，但不是 200 http 状态响应，api 响应的是 404 http 状态代码，这将引发异常。

所以我的问题是，在 API 中返回 40 倍的状态码真的是一种很好的做法，即使您发送和接收完美的请求也是如此？这不像是缺少参数、ID 等错误。这只是某种“布尔”查询，其中 return 可以是 true 或 false，而 false 将始终返回 40 倍的 http 状态代码，但仍包含有效响应。

谢谢

Answer 1

抛出异常的包是最好的类型，因为您可以简单地为这些异常编写“全局”处理程序并简单地“显示”发送的错误，但您不应该这样做。

您应该为 Twitch API 包编写一个 API 适配器，并在这些方法中处理错误/异常，而不是直接在控制器或模型中使用 Twitch 包。此外，您应该将请求委托给专用服务器（例如 Twitch）以进行排队作业。

回答你的问题：

API 中的 HTTP 状态代码是好的做法吗？

是的，您还想在哪里使用状态码？ API 是一个完美的地方。
状态码易于比较，易于理解。发送的消息只是人类“了解”正在发生的事情的元信息。

---

以下部分超出了问题的范围：

您应该从不更改包代码本身（测试时除外），而是克隆/分叉包，进行您需要的更改并使用 composer 来加载您的版本。

composer.json

"repositories": [
    {
        "type": "vcs",
        "url": "https://github.com/username/repository"
    }
],
"require": {
    .
    .
    .
    "original-repo-package": "dev-branch-form-your-repo as 1.0.0"
}