我的应用程序发送给第三方SOA服务器的数据是复杂的XML.服务器所有者确实提供了XML模式(.xsd
),并且由于服务器拒绝无效的XML消息,我需要在发送之前在本地验证它们.
我可以使用独立的XML模式验证器,但它们很慢,主要是因为解析模式文件所需的时间.所以我以HTTP服务器的形式编写了我自己的模式验证器(在Java中,如果这很重要),缓存已经解析的模式.
问题是:在验证过程中很多事情都可能出错.除意外异常和成功验证外:
服务器可能找不到指定的模式文件
指定的文件可能不是有效的模式文件
XML对模式文件无效
由于它是HTTP服务器,我想为客户端提供有意义的状态代码.对于上述所有情况,服务器是否应答400错误(错误请求)?或者它们与HTTP无关,它应该在正文中回复200并带有消息?还有其他建议吗?
更新:主应用程序是用Ruby编写的,它没有一个好的xml架构验证库,因此单独的验证服务器不会过度工程.
状态代码422("Unprocessable Entity")听起来足够接近:
"422(不可处理的实体)状态代码表示服务器理解请求实体的内容类型(因此415(不支持的媒体类型)状态代码是不合适的),并且请求实体的语法是正确的(因此是400(差)请求)状态代码是不合适的)但是无法处理包含的指令.例如,如果XML请求主体包含格式正确(即语法正确)但语义错误的XML指令,则可能发生此错误情况.
将验证过程中的错误情况映射到有意义的HTTP状态代码是完全有效的思考.
我假设您使用URI将XML文件作为POST内容发送到验证服务器,以确定用于验证的特定架构.
所以这里有一些错误映射的建议:
200:XML内容有效
400:XML内容格式不正确,标头不一致,请求与RFC 2616语法不匹配
401:在缓存中找不到架构,并且服务器需要用于对第三方SOA后端进行身份验证的凭据才能获取架构文件
404:找不到架构文件
409:XML内容对指定的模式无效
412:指定的文件不是有效的XMl模式
500:验证服务器中的任何意外异常(NullPointerExceptions等)
502:在缓存中找不到模式,并且尝试从第三方SOA服务器请求它失败.
503:验证服务器正在重启
504:使用reason = timeout查看502
亚马逊可以用作如何将http状态代码映射到实际应用程序级别条件的模型:http: //docs.amazonwebservices.com/AWSImportExport/latest/API/index.html?Errors.html(请参阅Amazon S3状态代码标题)
假设您要将XML文件发布到资源,例如:
POST/validator内容类型: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.