Spring JPA - RESTful частичное обновление и проверка для сущности

Question

У меня есть простой RESTful API, основанный на Spring MVC, использующий базу данных MySQL, связанную с JPA. До сих пор этот API поддерживает только полное обновление сущности. Это означает, что все поля должны быть предоставлены внутри тела запроса.

@ResponseBody
@PutMapping(value = "{id}")
public ResponseEntity<?> update(@Valid @RequestBody Article newArticle, @PathVariable("id") long id) {

    return service.updateById(id, newArticle);
}

Настоящая проблема здесь - проверка, как я могу проверить только предоставленные поля, в то время как все еще требуются все поля при создании?

@Entity
public class Article {

    @NotEmpty @Size(max = 100) String title;
    @NotEmpty @Size(max = 500) String content;

    // Getters and Setters
}

Пример тела запроса частичного обновления {"content": "Just a test"} вместо {"title": "Title", "content": "Just a test"}. Фактическое частичное обновление выполняется путем проверки, не является ли данное поле пустым:

if(newArticle.getTitle() != null) article.setTitle(newArticle.getTitle());

Но проверка, конечно, не сработает! Я должен деактивировать проверку для метода обновления для запуска службы RESTful. По сути, у меня два вопроса:

• Как проверить только "существующее" подмножество свойств в обновить метод, в то время как все еще требуется все поля при создании?
• Есть ли более элегантный способ частичного обновления, чем проверка на нуль

Answer 1

Сложность частичных обновлений и Spring JPA заключается в том, что вы можете отправить половину заполненных полей, и даже вам нужно будет извлечь всю сущность из базы данных, а затем просто «объединить» и сущность, и pojo, потому чтов противном случае вы рискуете своими данными, отправляя нулевые значения в базу данных.

Но объединение само по себе довольно сложно, потому что вам нужно работать над каждым полем и принять решение либо отправить новое значение в базу данныхили просто сохранить текущий.И когда вы добавляете поля, проверка должна обновляться, и тесты становятся более сложными.В одном утверждении: не масштабируется .Идея состоит в том, чтобы всегда писать код, который открыт для расширения и закрыт для изменений.Если вы добавите больше полей, тогда блок проверки в идеале не нужно менять.

Способ, которым вы справляетесь с этим в модели REST, заключается в том, что каждый раз, когда вам нужно, оперируйте всей сущностью.Допустим, у вас есть пользователи, затем вы сначала тянете пользователя:

GET /user/100

Затем у вас на веб-странице есть все поля с идентификатором пользователя = 100.Затем вы меняете его фамилию.Вы распространяете изменение, вызывая тот же URL ресурса с глаголом PUT:

PUT /user/100

И отправляете все поля, или, скорее, «ту же сущность» обратно с новым именем.И вы забудете о проверке, проверка будет работать как черный ящик.Если вы добавите больше полей, вы добавите больше @NotNull или любой другой необходимой вам проверки.Конечно, могут быть ситуации, когда вам действительно нужно написать блоки кода для проверки.Даже в этом случае на валидацию не влияют, так как у вас будет основной цикл for для вашей валидации, и у каждого поля будет свой валидатор.Если вы добавляете поля, вы добавляете валидаторы, но основной блок валидации остается недоступным.

Answer 2

Это самые основные опции для проверки сущности:

1. Вы можете аннотировать столбец с помощью @NotNull, как вы это делали с другими ограничениями.
2. Вы можете аннотировать полес @Column(nullable = false).

@Valid, с другой стороны, проверяется объект перед входом в метод.