在我的应用程序发送到第三方 SOA 服务器的数据中，有复杂的 XML。.xsd服务器所有者确实提供了XML 模式（
我可以使用独立的 XML 模式验证器，但它们很慢，主要是因为解析模式文件需要时间。因此，我以HTTP 服务器的形式编写了自己的模式验证器（如果重要的话，用 Java），它缓存已经解析的模式。
问题是：在验证过程中，很多事情都可能出错。除了意外异常和成功验证：
由于它是一个 HTTP 服务器，我想为客户端提供有意义的状态代码。对于上述所有情况，服务器是否应该以400错误（错误请求）回答？或者它们与 HTTP 无关，它应该在正文中回复200消息？还有什么建议吗？
更新：主应用程序是用Ruby编写的，它没有一个好的 xml 模式验证库，所以单独的验证服务器并没有过度设计。
状态码 422（“无法处理的实体”）听起来很接近：
“422（Unprocessable Entity）状态码意味着服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此 400（Bad "
将验证过程中的错误情况映射到有意义的 HTTP 状态代码是一种完全有效的想法。
我想您使用 URI 将 XML 文件作为 POST 内容发送到您的验证服务器，以确定用于验证的特定模式。
所以这里有一些关于错误映射的建议：
假设您将 XML 文件发布到资源，例如：
POST /validator 内容类型：application/xml
如果请求实体未能解析为它提交的媒体类型（即应用程序/xml），则 400 Bad Request 是正确的状态。
如果它在语法上解析为它提交的媒体类型，但它没有针对某些所需的模式进行验证，或者具有使其提交到的资源无法处理的语义 - 那么 422 Unprocessable Entity 是最好的状态（尽管你可能应该在错误响应中伴随一些更具体的错误信息；还请注意，它在技术上定义在 HTTP 的扩展中，WebDAV，尽管在 HTTP API 中被广泛使用，并且比任何其他 HTTP 错误状态更合适，当有已提交实体的语义错误）。
如果它作为媒体类型提交，这意味着 xml 之上的特定模式（例如 application/xhtml+xml），那么如果它无法针对该模式进行验证，您可以使用 400 Bad Request。但是，如果它的媒体类型是纯 XML，那么我认为模式不是媒体类型的一部分，尽管它有点灰色地带；如果 xml 文件指定了它的模式，您可能会将验证解释为 application/xml 语法要求的一部分。
如果您通过 multipart/form 或 application/x-www-form-urlencoded 表单提交来提交 XML 文件，那么您必须使用 422 Unprocessable Entity 来解决 XML 文件的所有问题；仅当基本表单上传存在语法问题时，400 才合适。
Amazon 可用作如何将 http 状态代码映射到实际应用程序级别条件的模型： http ://docs.amazonwebservices.com/AWSImportExport/latest/API/index.html?Errors.html （请参阅 Amazon S3 状态代码标题)
从 w3c：400 = 由于语法错误，服务器无法理解请求。
除非实际上是服务器无法理解请求的情况，否则我不会提供该服务。如果您只是获得无效的 xml，请提供 200 并解释为什么事情不起作用。
假的
我会400 Bad request在正文中添加更具体的消息（可能在标题中带有辅助错误代码，X-Parse-Error: 10451以便于处理）
这听起来是个不错的主意，但 HTTP 状态代码并没有真正提供“操作失败”的情况。我将返回带有X-Validation-Result: true/false标头的 HTTP 200，必要时将正文用于任何文本或“原因”。将 HTTP 4xx 保存为 HTTP 级错误，而不是应用程序级错误。
不过，这是一种耻辱和双重标准。许多应用程序使用 HTTP 身份验证，它们能够从应用程序级别返回 HTTP 401 Not Authorized 或 403 Forbidden。拥有某种可以使用的全面的 HTTP 4xx Request Rejected 会很方便和明智。