部分成功请求的 HTTP 状态代码
我有一个向用户发送消息的应用程序。在 post 请求中传输一个 XML 字符串，该字符串由应接收该特定消息的所有用户组成。如果列表中的任何用户不存在，我会将丢失用户的列表返回给客户进行进一步评估。
现在我问自己，应用程序的正确状态代码是什么，表示请求已被接受，但有些事情无法完成。
如果不允许在列表中包含丢失的用户，则可以避免该问题。然后发送尝试只会得到一个 4xx 错误。但是以这种方式形成 API 是没有意义的。另一方面，我可以认为错误条件纯粹是特定于应用程序的。但是发送 200 感觉不对。最好给客户一个提示，什么时候深入查看错误响应。例如，避免一遍又一遍地向该用户发送消息
我处理过一个非常相似的问题。在这种情况下，我返回了一个
207 多状态
现在，这不是严格的 HTTP，它是 WebDAV 扩展的一部分，所以如果您也无法控制客户端，那么这对您不利。如果你这样做，你可以这样做：
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:user>user-123</D:user>
<D:status>success</D:status>
</D:response>
<D:response>
<D:user>user-789</D:user>
<D:status>failure</D:status>
</D:response>
</D:multistatus>
但同样，这是一个 HTTP 扩展，您还需要控制客户端。
我遇到了同样的问题，我最终使用了两种不同的解决方案：
HTTP 返回码 202：已接受，表示请求正常，但不能保证一切都按预期进行。
在响应中返回正常的 200，但在响应正文中包含未成功的列表。
第二个通常效果最好，但如果你很懒或使用队列进行处理，第一个很好。
我需要同样的问题，在阅读了一些文档之后，这个问题的最佳解决方案似乎是用非标准的 2xx 响应来响应。一般客户会将此视为成功，但特定客户可以理解发生了什么。您也可以使用表单 X-failed: thispart code 中的自定义标题来支持这一点。您可能应该将操作的问题作为文本包含在内，以便通用客户端能够显示发生的事情的性质。这是我在上传文件但目前无法完成处理的地方所做的事情：
HTTP/1.1 210 Partial success
X-failed: processing
X-reason: server busy
File has been uploaded, however, the task associated with the
file has not started as the server is busy. Re-request processing
at a later time.
使用 206 部分内容怎么样。我知道 206 更多的是关于范围，但是如果它可以指示部分成功的请求怎么办？
The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional. w3.org/Protocols/rfc2616/rfc2616-sec10.html
超文本传输协议处理事物的传输方面。它没有处理应用程序级错误的错误代码。
返回 200 是正确的做法。就 HTTP 而言，请求被正确接收，处理得当，并且您正在发回响应。因此，在 HTTP 级别上一切正常。与在 http 之上运行的应用程序相关的任何错误或警告都应包含在响应中。这样做还可以防止您在使用代理服务器时遇到的一些令人讨厌的问题，这些问题可能无法按您期望的方式处理某些响应。
