【发布时间】:2016-02-26 16:02:41
【问题描述】:
我必须遵循泽西岛的端点结构:
/objects/
/objects/:id
/objects/:id/:field
/objects/:id/:field/:subfield
我使用的 ID 具有非常特定的格式,因此在向数据库发出请求之前,我首先检查格式是否有效。
现在我必须将这段代码放入每个以:id 为参数的函数的POST、PUT、GET、DELETE 函数中。所以这只是意味着提前返回。
if (!isIdValid(id)){
return Response.status(Response.StatusType.BAD_REQUEST)
.entity("The ID you've provided is invalid")
.build();
}
(实际上错误实体是一个包含更多错误信息的对象)
然后对于使用:field 或:subfield 参数的每个函数,代码类似。每次都必须复制这种检查和错误处理行为。当我开始复制粘贴内容时,我开始思考:应该有更好的方法吗?
我想将:id 检查代码放在/objects/:id 级别,然后假设所有进一步的嵌套级别都有一个有效的ID。进一步嵌套的其他参数也是如此。
我一直在研究使用子资源定位器,但随后您创建了一个返回子资源新实例的函数。如果验证失败,我无法将Response-object 的条件返回置于该级别。
@Path("{id}")
function Class<ObjectFieldResource> getObjectById(@PathParam("id") String id){
return ObjectFieldResource.class;
}
我可以开始抛出异常,但我宁愿避免这种情况,因为我并不认为无效输入是一个异常。
如何最好地实施这样的结构?我查看了 bean 验证,但这似乎不允许我为我的特定格式 + 自定义错误响应定义验证。
我在实现子资源的方式上是否遗漏了什么?
【问题讨论】:
-
我知道你说过你不喜欢异常,但你可以有一个 checkID 方法抛出一个异常,然后使用映射器将该异常转换回具有相关信息的响应。 jersey.java.net/documentation/latest/…
-
我目前有一个通用的异常映射器可以做到这一点。但我确实可以为每种验证错误创建单独的异常类。不过很容易失控。但如果这是要走的路……
标签: java api rest validation jersey