据我所知:

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

我正在使用 Spring 来实现一个非常简单的 HTTP 服务器。当用户想要更新他的数据时，他需要创建一个 HTTP PATCH到某个端点(假设: api/user )。他的请求正文通过 @RequestBody 映射到 DTO ，看起来像这样:

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存在是有原因的。

最佳答案

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 request 表示要应用于我们需要显式建模的资源的更改。

一种方法是使用普通的旧 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)
}

上面的内容很容易理解:

• 我们没有验证请求值

可以通过在域层对象上引入验证注释来缓解上述情况。虽然这在简单的场景中非常方便，但一旦我们引入 conditional validation 就会变得不切实际。取决于域对象的状态或执行更改的主体的角色。更重要的是，在产品存在一段时间并引入新的验证规则之后，仍然允许在非用户编辑上下文中更新实体是很常见的。看来enforce invariants on the domain layer 比较务实但是 keep the validation at the edges .

• 可能在很多地方都非常相似

这实际上很容易解决，在 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))
        }
    }
}

验证请求

感谢 delegated properties in 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 接口(interface)我们可以过滤掉与请求中不存在的属性相关的错误，如下所示:

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 来简化开发。我在下面做了。

最简单的解决方案

我认为将上面描述的内容包装到一个简单易用的库中是有意义的 - 看吧 patchy .使用 patchy 可以有一个强类型的请求输入模型以及声明性验证。您只需导入配置@Import(PatchyConfiguration::class)并实现PatchyRequest模型中的接口(interface)。

进一步阅读

• Spring Sync
• fge/json-patch

https://stackoverflow.com/questions/36907723/