如何在基于Spring的强类型语言中正确地进行PATCH - 例子

Question

根据我的知识:

• PUT - 用其整个表示更新对象(替换)
• PATCH - 仅使用给定字段更新对象(更新)

我正在使用Spring来实现一个非常简单的HTTP服务器.当用户想要更新他的数据时,他需要将HTTP PATCH发送到某个端点(比方说:) api/user.他的请求体被映射到DTO via @RequestBody,如下所示:

class PatchUserRequest {
    @Email
    @Length(min = 5, max = 50)
    var email: String? = null

    @Length(max = 100)
    var name: String? = null
    ...
}

然后我使用这个类的对象来更新(补丁)用户对象:

fun patchWithRequest(userRequest: PatchUserRequest) {
    if (!userRequest.email.isNullOrEmpty()) {
        email = userRequest.email!!
    }
    if (!userRequest.name.isNullOrEmpty()) {
        name = userRequest.name
    }    
    ...
}

我的疑问是:如果客户(例如网络应用程序)想清除房产怎么办？我会忽略这样的改变.

我怎么知道,如果用户想要清除一个属性(他故意将我命名为null)或者他只是不想改变它？在两种情况下,它在我的对象中都是null.

我可以在这里看到两个选项:

• 同意客户,如果他想删除一个属性,他应该给我一个空字符串(但是日期和其他非字符串类型呢？)
• 停止使用DTO映射并使用一个简单的映射,这将让我检查字段是否为空或根本没有给出.那么请求身体验证呢？我@Valid现在用.

如何妥善处理此类案件,与REST和所有良好做法保持一致？

编辑:

可以说不PATCH应该在这样的例子中使用,我应该PUT用来更新我的用户.但是模型更改怎么样(例如添加新属性)？每次用户更改后,我都必须对我的API(或单独的用户端点)进行版本控制.例如,我将有api/v1/user终点,它接受PUT一个老请求主体和api/v2/user它接受端点PUT一个新的请求主体.我想这不是解决方案而且PATCH存在是有原因的.

Answer 1

TL; DR

patchy是我提出的一个小型库,它负责处理PATCH在Spring中正确处理所需的主要样板代码,即:

class Request : PatchyRequest {
    @get:NotBlank
    val name:String? by { _changes }

    override var _changes = mapOf<String,Any?>()
}

@RestController
class PatchingCtrl {
    @RequestMapping("/", method = arrayOf(RequestMethod.PATCH))
    fun update(@Valid request: Request){
        request.applyChangesTo(entity)
    }
}

简单解决方案

由于PATCH请求表示要应用于资源的更改,因此我们需要对其进行显式建模.

一种方法是使用普通旧的Map<String,Any?>,其中key客户提交的每个都表示对资源的相应属性的更改:

@RequestMapping("/entity/{id}", method = arrayOf(RequestMethod.PATCH))
fun update(@RequestBody changes:Map<String,Any?>, @PathVariable id:Long) {
    val entity = db.find<Entity>(id)
    changes.forEach { entry ->
        when(entry.key){
            "firstName" -> entity.firstName = entry.value?.toString() 
            "lastName" -> entity.lastName = entry.value?.toString() 
        }
    }
    db.save(entity)
}

但是上面很容易理解:

• 我们没有验证请求值

通过在域层对象上引入验证注释可以减轻上述问题.虽然这在简单的场景中非常方便,但是一旦我们引入条件验证,取决于域对象的状态或执行更改的主体的角色,它往往是不切实际的.更重要的是,在产品存在一段时间并引入新的验证规则之后,仍然允许实体在非用户编辑上下文中进行更新是很常见的.在域层上强制实施不变量似乎更实用,但要在边缘保持验证.

• 在很多地方都会非常相似

这实际上非常容易解决,在80%的情况下,以下方法可以解决:

fun Map<String,Any?>.applyTo(entity:Any) {
    val entityEditor = BeanWrapperImpl(entity)
    forEach { entry ->
        if(entityEditor.isWritableProperty(entry.key)){
            entityEditor.setPropertyValue(entry.key, entityEditor.convertForProperty(entry.value, entry.key))
        }
    }
}

验证请求

感谢Kotlin中的委托属性,构建包装器非常容易Map<String,Any?>:

class NameChangeRequest(val changes: Map<String, Any?> = mapOf()) {
    @get:NotBlank
    val firstName: String? by changes
    @get:NotBlank
    val lastName: String? by changes
}

使用Validator接口我们可以过滤掉与请求中不存在的属性相关的错误,如下所示:

fun filterOutFieldErrorsNotPresentInTheRequest(target:Any, attributesFromRequest: Map<String, Any?>?, source: Errors): BeanPropertyBindingResult {
    val attributes = attributesFromRequest ?: emptyMap()
    return BeanPropertyBindingResult(target, source.objectName).apply {
        source.allErrors.forEach { e ->
            if (e is FieldError) {
                if (attributes.containsKey(e.field)) {
                    addError(e)
                }
            } else {
                addError(e)
            }
        }
    }
}

显然,我们可以简化HandlerMethodArgumentResolver我在下面所做的开发.

最简单的解决方案

我认为这将是有意义的包裹上述搞什么名堂成一个简单易用的库-见斑片状.对于补丁,可以使用强类型请求输入模型以及声明性验证.您所要做的就是在模型中导入配置@Import(PatchyConfiguration::class)和实现PatchyRequest接口.

进一步阅读

• 春天同步
• FGE/JSON-补丁

Answer 2

我遇到了同样的问题,所以这是我的经验/解决方案.

我建议你实现它应该的补丁,所以如果

• 一个键存在值>值已设置
• 一个键出现一个空字符串>设置空字符串
• 一个键带有空值>该字段设置为null
• 密钥不存在>该密钥的值不会更改

如果你不这样做,你很快就会得到一个难以理解的api.

所以我会放弃你的第一个选择

同意客户,如果他想删除一个属性,他应该给我一个空字符串(但是日期和其他非字符串类型呢？)

在我看来,第二种选择实际上是一个很好的选择.这也是我们所做的(有点).

我不确定您是否可以使验证属性与此选项一起使用,但是再次,如果此验证不在您的域层上吗？这可能会从域中抛出异常,该异常由其余层处理并转换为错误请求.

这就是我们在一个应用程序中完成它的方式:

class PatchUserRequest {
  private boolean containsName = false;
  private String name;

  private boolean containsEmail = false;
  private String email;

  @Length(max = 100) // haven't tested this, but annotation is allowed on method, thus should work
  void setName(String name) {
    this.containsName = true;
    this.name = name;
  }

  boolean containsName() {
    return containsName;
  }

  String getName() {
    return name;
  }
}
...

json反序列化器将实例化PatchUserRequest,但它只会为存在的字段调用setter方法.因此,缺少字段的contains布尔值将保持为false.

在另一个应用程序中,我们使用相同的原则,但有点不同.(我更喜欢这个)

class PatchUserRequest {
  private static final String NAME_KEY = "name";

  private Map<String, ?> fields = new HashMap<>();;

  @Length(max = 100) // haven't tested this, but annotation is allowed on method, thus should work
  void setName(String name) {
    fields.put(NAME_KEY, name);
  }

  boolean containsName() {
    return fields.containsKey(NAME_KEY);
  }

  String getName() {
    return (String) fields.get(NAME_KEY);
  }
}
...

您也可以通过让PatchUserRequest扩展Map来做同样的事情.

另一种选择可能是编写自己的json反序列化器,但我自己没有尝试过.

可以说在这样的例子中不应该使用PATCH,我应该使用PUT来更新我的用户.

我不同意这一点.我也像你说的那样使用PATCH&PUT:

• PUT - 用其整个表示更新对象(替换)
• PATCH - 仅使用给定字段更新对象(更新)