当只有部分数据可用时检索资源的 HTTP 响应答案

【问题标题】：HTTP response retrieving a resource when only partial data is available当只有部分数据可用时检索资源的 HTTP 响应
【发布时间】：2017-05-26 04:08:14
【问题描述】：

如果已经有答案，我深表歉意。我找到了相关的问题（例如HTTP status code for a partial successful request），但并不完全相同。

我正在构建一个返回从多个来源聚合的数据的 API。有时，数据的某些关键部分不可用，必须让客户端知道并在响应中包含错误数据。

除了缺少字段的严重性之外，资源的其余部分是有效和有用的，可以被视为部分更新（例如，如果您只有权限查看资源的一部分）。

到目前为止，选项是

返回 200，将其视为部分资源，像处理任何其他数据一样处理应用程序中的错误数据字段
返回 207 以强调它没有完全成功，但 207 并不是严格意义上的 HTTP。
返回 500 并在应用程序中处理成功返回的数据，就像在 200 上一样

我偏爱选项 1，但我并不完全相信。有没有明确的处理方法？也许定义一个特定的content-type？

【问题讨论】：

它是主观的，我个人认为500是合适的，因为数据是错误的，它不符合相应请求的期望。您可以添加任何您喜欢的自定义响应标头，例如X-Response-Type: partial 并指示您的客户在处理响应数据之前参考该值，如果他们收到代码 500
嗨@AlexK。我可以看到 500 的情况，但是由于我们以一种有用的方式专门处理数据的缺失，并且资源可以（并且是）以一致的方式返回，所以 200 会更合适。如果你想画一个平行线，我会说它类似于代码中的已处理异常，而 500 类似于未处理的异常。也许这不是一个很好的平行线？我们正在返回一个内容类型，突出显示部分信息以提醒客户。从你的 POV 来看，这有意义吗？
就我个人而言，我会返回 200 并指出响应正文中缺少哪些数据（您的选项 #1）。据我所知，REST 非常以资源为中心，因为在您的情况下，资源是有效且有用的（换句话说，“它存在”），200 似乎成为最佳选择。愚弄content-type 也可能不是一个好主意，因为这可能会使一些客户感到困惑。只需使用普通的application/json（或 XML）即可。我还注意到许多 API 倾向于“错误”地处理 200 并将丰富的状态作为数据返回。这种方式似乎更“惯用”。

标签： rest api http http-response-codes

【解决方案1】：

您在这里忽略了这一点，因为 500 表示系统或通信链出现故障，并且由于返回了数据，因此必须假定资源存在并且已找到。 OP 所指示的是部分结果，暗示与资源有关的复合数据。这必然超出了 http 的范围，它通过成功的 200 完成了它的工作，除非您选择了一个合同，其中部分数据是错误的，因此是 40 倍。

【讨论】：

我的想法完全正确，但是（我想我可能对我的问题更清楚）系统依赖于从多个来源聚合的数据，并且由于随机原因导致来源不可用，个别字段可能会丢失。换句话说，通信链上的故障。问题是，在复杂的聚合系统中，这些故障可能很常见，返回的正确状态代码是什么。