Шаблон частичного совпадения API REST - объект имеет отношения «многие ко многим» и «один ко многим»

Question

У меня есть несколько сложный объект домена, такой как:

public class User implements Serializable {

    private Long id;
    private String firstName;
    private String lastName;
    private Boolean isActive;
    private List<Company> comapnies;
    private List<Department> departments;
    private List<Responsibility> responsibilities;
    private List<ContactInformation> contactInformation;
}

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

Я не хочу делать полное обновление объекта каждый раз из-за задержки в сети.Поэтому я хочу сделать частичное обновление (PATCH)

. Прямо сейчас у меня есть пользовательский объект данных с именем "UpdateUser", и этот объект выглядит следующим образом:

public class UpdateUser implements Serializable {

    private User user;
    private List<Company> comapnies_to_add;
    private List<Company> comapnies_to_remove;
    private List<Department> departments_to_add;
    private List<Department> departments_to_remove;
    private List<Responsibility> responsibilities_to_add;
    private List<Responsibility> responsibilities_to_remove;
    private List<ContactInformation> contactInformation_to_add;
    private List<ContactInformation> contactInformation_to_remove;
}

Затем конецТочка по существу будет модульно выполнять каждое из этих действий (если ответственность_to_add.length> 0 обрабатывает добавление обязанностей).

Мой вопрос больше связан с шаблоном - я чувствую, что это "хакер".Хотелось бы, чтобы был способ использовать частичное обновление только для объекта User, вместо того, чтобы иметь собственную конечную точку с пользовательским объектом UpdateUser.Существует ли более чистый способ обработки частичного обновления, который включает в себя отношения «один ко многим», «многие ко многим» и т. Д.

Я использую библиотеки Spring REST API + Java, в том числе это помогает.

Редактировать

Я полагаю, эта часть также имеет значение - я мог бы легко делегировать ответственность за удаление / добавление объектов для каждой из этих коллекций в пользовательском для другой конечной точки (яна самом деле уже есть), но я хотел единую конечную точку для приложения, чтобы мы могли обрабатывать все транзакции.

Answer 1

Существует ли более чистый способ обработки частичного обновления, который включает отношения один-ко-многим, отношения многие-ко-многим и т. Д.

Трудно сказать - это зависито том, какая часть работы доставляет вам неприятности.

PATCH и, аналогично, PUT, экспресс-семантика редактирования документов - в обоих случаях мы просим, ​​чтобы сервер сделал представление некоторого ресурсасоответствует представлению клиента.

I GET /foo, и вы, в свою очередь, отправляете мне документ json объемом 1 ГБ.Я загружаю этот документ в редактор json и исправляю одну или две орфографические ошибки.Поскольку изменения невелики, я мог бы отправить вам запрос PATCH, а не отправлять обратно 1 ГБ json.Это означает, что я создам представление своих правок в каком-либо типе носителя, который вы и я понимаем, и отправлю вам это представление.

application / json-patch + json может бытьХорошая отправная точка.

Хорошая вещь в использовании стандартов заключается в том, что большая часть работы уже сделана для вас.Но вместо этого вы могли бы разработать собственную схему документа исправления, если бы у вас была такая склонность, и опубликовать ее, и любой клиент, который понимал вашу схему, мог бы взаимодействовать с вами.

Обратите внимание, что все это происходит вдомен "передача документов по сети".Здесь ничего не происходит, что подразумевает, что клиент знает, что существует объектная модель, или таблицы реляционной базы данных, или какая-либо другая деталь реализации, подобная этой.Это просто проблема сервера.

Конечно, вторая часть проблемы сейчас: вот я, сервер с патч-документом и одиннадцатью таблицами в моей реляционной базе данных, которые могут нуждаться в обновлении.Как это происходит?Как отметил Джон, это работа, которую необходимо выполнить.Один из возможных ответов в мире Java / Spring / Hibernate заключается в том, что вы можете загрузить текущее состояние серверной части через ORM, использовать патч для направления изменений в локальную структуру данных в памяти, а затем попросить ORM выяснить, чтооператоры должны быть выполнены.

Answer 2

Ранее я решал эту проблему двумя способами.

1. Как вы упомянули.Наличие делегатов, которые обрабатывают логику и маршруты к соответствующим методам хранилища crud

2. Используйте HTTP-метод PATCH.Обратите внимание, что это только семантика.Фактическая логика все еще должна выполняться вами, как и любым другим методом HTTP.

Пример здесь: https://github.com/jersey/jersey/tree/master/examples/http-patch