REST资源类中用于封装错误处理的好模式或样式是什么？

Question

我已多次遇到这种模式。在伪代码中：

public class BlahResource { if (thisError) buildResponse(BAD_REQUEST); if (thatError) buildResponse(CONFLICT); ... doSomething(); return buildResponse(SUCCESS); }

看起来并不太糟糕，但是当你有一百万个错误条件要处理时，太多的业务逻辑会累积到Resource类中，并且噪声很快就会破坏代码实际上正在做什么的故事

由于在资源中错误条件正在返回某些内容，因此从服务中抛出的异常对我来说似乎不对。并且封装返回条件和设置的不同组合的状态对象看起来有点矫枉过正。

是否有一些显而易见的东西我不知道如何以合理，清晰的方式对其进行编码？可能是我缺少的功能性/番石榴/基于lambda的东西，或者只是常规的OO解决方案。

Answer 1

有一个完整的JSR-349 Bean Validation规范解决了这些问题

来自规范目标

  

验证数据是一项在整个过程中发生的常见任务   应用程序，从表示层到持久层。   通常在每一层中实现相同的验证逻辑，证明   是耗时和错误的。避免重复这些   在每一层的验证中，开发人员经常捆绑验证逻辑   直接进入域模型，用域杂乱的域类   事实上，验证代码是关于类本身的元数据。   此JSR为JavaBean验证定义了元数据模型和API。该   默认元数据源是注释，具有覆盖功能   并通过使用XML验证扩展元数据   描述符。

hibernate-validator是参考实现，但请注意，实现不依赖于任何层（也不是Web，也不是持久层）

回到你的资源代码，这意味着，通过利用自定义约束，你的资源看起来像

public class BlahResource {
  @CheckBadRequest
  @CheckConflict
  private field
  ...
}

验证失败时，错误存储在ConstraintViolation内，您可以通过Validator界面获取。这些是您应该构建错误处理机制的中心点，同样是伪

Set<Constraintviolation<Resource>> violations = validator.validate(Resource);