Джерси: Лучший обработки успокоительный HTTP PUT (обновление) запрос

Question

практика Предположим, что у меня есть очень простой User класс:

@JsonIgnoreProperties({"password", "created", "lastModified"}) 
public class User { 
    public String id; 
    public String name; 
    public String password 
    public Long created; 
    public Long lastModified; 
} 

Когда мы сериализовать User объект в JSON строку, мы отфильтровывать password, created и lastModified. И затем пользователь в передней части обновит имя пользователя и вернет пользователя обратно в нашу службу Restful.

И мой псевдо метод контроллера обработки PUT запрос:

@Path("/user/{id}") 
@POST 
@Consumes(MediaType.APPLICATION_JSON) 
public void saveUpdate(@PathParam("id")String id, User user) { 
    userService.save(user); 
} 

В приведенном выше методе я ожидаю Джексон десериализации строку JSON, посланный передним концом к user например POJO, а затем позвоните в нашу службу, чтобы сохранить экземпляр.

Пока все выглядит круто. Однако беспокойство возникает, когда мы передаем user POJO на номер userService, чтобы сохранить его. Помните, что у нас есть три свойства, которые игнорируются, когда мы сериализуем user в JSON: password, created, lastModified, и мы должны получить значение этих недостающих свойств из базы данных, а затем объединить с данными, отправленными с передней стороны.

Выполнение операции слияния - очень простая, но утомительная задача для кодера. Мне было интересно, есть ли какие-либо хорошие методы для легкого и изящного решения этого случая.

Answer 1

Я полагаю, что объект User является объектом сущности, который будет сохранен в БД, поэтому наилучшей практикой является не подвергать объекты объекта FE, но использовать объекты DTO, которые содержат только те поля, которые FE должен знать (подумайте о том, чтобы скрыть идентификатор и использовать UUID вместо этого, поскольку значения id предсказуемы). Позже вы можете сопоставить такой объект DTO с Entity, используя ModelMapper, чтобы вы могли легко объединиться между объектами userDTO и объектами пользователя, а затем просто сохранить объект, не беспокоясь о состоянии отсутствующих полей.

Кроме того, сегодня многие веб-службы отключили запросы PUT для своих приложений и вместо этого использует POST. Я не знаю много причин, но это было одной из проблем безопасности, когда мы передали приложение на проверку безопасности.

Answer 2

Я думаю, что проблема связана скорее с вашей службой, чем с REST API. Я имею в виду, что если пользовательские свойства 3 «пароль», «созданный» и «последниймодифицированный» не должны быть видимыми для уровня представления, тогда служба должна иметь возможность обрабатывать сохранение без них.

В постоянном слое вы можете обязательно обновить User без всех заполненных объектов. Разделите UserLogin («id», «password», «created», «lastModified») и «User» («id», «name»), которые указывают на ту же таблицу DB. Тогда обновление для Пользователя вообще не нуждается в других ненужных свойствах.