Обычный шаблон, который нужно использовать, будет рассматривать это как проблему удаленной авторизации.
Основная идея удаленной авторизации заключается в том, что мы запрашиваем у сервера текущее представление ресурса. Затем мы вносим локальные (для клиента) изменения в представление, а затем запрашиваем, чтобы сервер принял наше представление в качестве замены.
Таким образом, мы могли бы GET представление, включающее массив JSON-компонентов. В нашей локальной копии мы удаляем ингредиенты, которые нам больше не нужны, добавляем новые. В этом случае мы PUT возвращаем нашу локальную копию на сервер.
Когда документы очень большие, с изменениями, которые легко описать, мы могли бы вместо отправки всего документа на сервер вместо отправки запроса PATCH с «документом исправления», который описывает изменения, которые мы внесли локально.
Когда сервер является просто хранилищем документов, реализация на сервере проста - вы можете просмотреть изменения, чтобы решить, являются ли они действительными, вычислить новое представление (при необходимости), а затем сохранить его в файл, или что угодно.
Когда вы используете реляционную базу данных? Затем реализация сервера должна выяснить, как обновить себя. Библиотека ORM может сэкономить вам кучу работы, но нет никаких гарантий - люди, как правило, оказываются запутанными в конце «объекта» «объектно-реляционного сопоставителя». Возможно, вам придется вернуться к собственному усмотрению, катя собственный SQL.
Альтернативой удаленной авторизации является рассмотрение проблемы как веб-сайта. В этом случае вы получите некоторое представление формы, которая позволяет клиенту описать изменения, которые должны быть внесены, а затем отправить форму, создав запрос POST, описывающий предполагаемые изменения.
Но вы столкнулись с той же проблемой сопоставления на стороне сервера - сколько вам нужно сделать, чтобы преобразовать запрос POST в правильную транзакцию базы данных?
REST, увы, ничего не говорит вам о том, как преобразовать представление, представленное в запросе, в вашу реляционную базу данных. В конце концов, это часть point - REST предназначена для того, чтобы позволить вам заменить сервер альтернативной реализацией, не ломая существующих клиентов, и наоборот.
Тем не менее, да - ваши основные идеи верны; вы можете просто заменить все существующее представление в вашей базе данных, или вместо этого вы можете оптимизировать, чтобы только внести необходимые изменения. ORM может быть в состоянии эффективно выполнить преобразования для вас - известно, что такие оптимизации, как отложенная загрузка, значительно усложняют ситуацию.