我的应用程序发送给第三方SOA服务器的数据是复杂的XML。服务器所有者确实提供了XML模式（.xsd），并且由于服务器拒绝无效的XML消息，我需要在发送之前在本地验证它们。
我可以使用独立的XML模式验证程序，但它们很慢，主要是因为解析模式文件所需的时间。所以我以 HTTP Server 的形式编写了我自己的模式验证器（在Java中，如果这很重要），它缓存已经解析过的模式。
问题是：在验证过程中很多事情都可能出错。除了意外的例外和成功的验证：
由于它是HTTP服务器，我想为客户端提供有意义的状态代码。对于上述所有情况，服务器是否应回答 400 错误（错误请求）？或者它们与HTTP无关，它应该在正文中回复 200 ？还有其他建议吗？
更新：主应用程序是用 Ruby 编写的，它没有一个好的xml架构验证库，因此单独的验证服务器不会过度工程化。
答案 0 :(得分：28)
Status code 422 ("Unprocessable Entity")听起来足够接近：
“422（不可处理的实体）状态代码表示服务器理解请求实体的内容类型（因此415（不支持的媒体类型）状态代码是不合适的），并且请求实体的语法是正确的（因此a 400（错误请求）状态代码是不合适的）但是无法处理包含的指令。例如，如果XML请求主体包含格式正确（即语法正确）但语义错误的XML指令，则可能发生此错误情况。 “
答案 1 :(得分：15)
将验证过程中的错误情况映射到有意义的HTTP状态代码是完全有效的思考。
我想您使用URI将XML文件作为POST内容发送到验证服务器，以确定用于验证的特定架构。
以下是错误映射的一些建议：
答案 2 :(得分：5)
亚马逊可以用作如何将http状态代码映射到实际应用程序级别条件的模型： http://docs.amazonwebservices.com/AWSImportExport/latest/API/index.html?Errors.html（请参阅Amazon S3状态代码标题）
答案 3 :(得分：5)
假设您要将XML文件发布到资源，例如：
POST /验证器 内容类型：application / xml
如果请求实体无法解析为提交的媒体类型（即application / 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.
答案 4 :(得分：3)
来自w3c： 400 =由于语法格式错误，服务器无法理解请求。
除非事实上服务器无法理解请求，否则我不会提供服务。如果您只是获取无效的xml，请提供200并解释为什么事情无效。
此致 假
答案 5 :(得分：2)
我会使用400 Bad request并在正文中添加更具体的消息（可能在标题中包含辅助错误代码，例如X-Parse-Error: 10451以便于处理）
答案 6 :(得分：-1)
这听起来像一个简洁的想法，但HTTP状态代码并没有真正提供“操作失败”的情况。我会返回带有X-Validation-Result: true/false标头的HTTP 200，根据需要使用正文任意文本或“原因”。将HTTP 4xx保存为HTTP级错误，而不是应用程序级错误。