如何基于Spring在强类型语言中正确执行PATCH-示例

小编典典

如何基于Spring在强类型语言中正确执行PATCH-示例

spring-boot

据我了解：

PUT -更新对象的整体表示形式（替换）
PATCH -仅使用给定字段更新对象（更新）

我正在使用Spring来实现一个非常简单的HTTP服务器。当用户想要更新其数据时，他需要PATCH对某个端点进行HTTP
（比如说：）api/user。他的请求正文通过映射到DTO @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
    }    
    ...
}

我的疑问是：如果客户端（例如Web应用程序）想要清除财产该怎么办？我会忽略这样的变化。

我怎么知道，如果用户想清除某个属性（他故意给我发送了空值），或者只是不想更改它？在这两种情况下，我的对象都为null。

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

与客户达成协议，如果他要删除属性，则应给我发送一个空字符串（但是日期和其他非字符串类型呢？）
停止使用DTO映射，并使用一个简单的映射，这将使我检查字段是否为空或根本没有给出。那么请求主体验证呢？我@Valid现在用。

应如何与REST和所有良好实践相协调地妥善处理此类案件？

编辑：

可以说PATCH不应在这样的示例中使用它，而我应该使用它PUT来更新我的用户。但是，如何进行模型更改（例如添加新属性）？每次更改用户后，我都必须对API（或仅对用户端点）进行版本控制。例如，我将拥有api/v1/user接受PUT旧请求主体的api/v2/user端点，以及接受PUT新请求主体的端点。我想这不是解决方案，并且PATCH存在是有原因的。

阅读 400

2020-05-30

共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在模型中实现接口。

进一步阅读

2020-05-30