REST API 是否应该始终返回带有消息的响应？答案

【问题标题】：Should REST API always return response with a message?REST API 是否应该始终返回带有消息的响应？
【发布时间】：2022-01-10 09:08:47
【问题描述】：

我不确定在创建 API 服务器时是否应该在响应中包含成功消息。
就像当你 PUT 到 API 服务器并且后端成功创建了一些东西时，你可以得到一个带有 201 状态码的响应。
API 服务器是否应该包含如下消息：

{
  "message": "Successfully created."
}

作为响应中的 JSON？

【问题讨论】：

没有必要，它应该返回一个有意义的响应，您/您的客户可以在前端使用
我建议使用@hapi/boom库：hapi.dev/module/boom/api?v=9.1.4

标签： json api rest server backend

【解决方案1】：

REST API 是否应该始终返回带有消息的响应？

这不是必需的 - 我们在标准中有 204（无内容）和 205（重置内容），因为在某些情况下，没有正文的响应是有意义的。

但在我们发送 200/201 的常见情况下，我希望看到描述 the status of the action 的响应正文

201 响应内容通常描述和链接到所创建的资源。

【讨论】：

【解决方案2】：

不，例如，对于 204 响应，我们不能包含消息正文。 {success: true} 是多余的。

在实践中（或者我应该在更高版本的 jquery 中说），应用程序/json 内容类型的空响应会引发错误。我有点理解因为它是 application/json 它必须有一个有效的 json 主体的论点。因此，application/json 内容类型的空响应将是“null”或“{}”，它们是有效的 json。

还有另一种适用于 jquery 的方法，即不为空响应返回 application/json。只需使用 text/plain 或其他内容，并确保客户端可以处理该类型。

【讨论】：

【解决方案3】：

我同意 VoiceOfUnreason：这不是强制性的，但我通常会返回

{"status":"ok"}

如果我需要返回一些内容

{"status":"ok","result":{.....}}

而且，如果发生错误，我仍然更喜欢在应用程序级别返回 200 处理错误

{"status":"ko","errorMessage":"Something went wrong!"}

法比奥

【讨论】：