Лучшая практика для обновления дизайна RESTful API 1 / многие-ко-многим?

Предположим, у меня есть страница с рецептами, на которой рецепт может содержать несколько ингредиентов. Пользователи могут редактировать список ингредиентов и обновлять / сохранять рецепт. В базе данных есть следующие таблицы: таблица рецептов, таблица ингредиентов, ингридиент\_recipes\_table. Предположим, что в рецепте есть ингредиенты a, b, c, d, но затем пользователь меняет его на a, d, e, f. С запросом к серверу, я просто отправляю только новый список ингредиентов и заставляю бэкэнд определить, какие значения нужно удалить / вставить в базу данных? Или я явно указываю в полезной нагрузке, какие значения должны быть удалены и какие значения должны быть вставлены? Я предполагаю, что это, вероятно, первое, но тогда это обрабатывается до или во время запроса БД? Должен ли я сначала читать из таблицы, а затем писать после расчета различий? Или запрос просто обрабатывает это? Я искал и вижу решения, включающие INSERT IGNORE ... DELETE ... NOT IN ... или использование оператора MERGE. В проекте не используется ORM - могу ли я предположить, что это легко сделать с помощью ORM?              

Можете ли вы поделиться, как выглядит пользовательский интерфейс? Было бы довольно стандартной практикой, что вы можете опубликовать один новый ингредиент как действие или удалить один как действие. Вы можете просто иметь кнопку рядом с ингредиентами, чтобы инициировать запрос DELETE, и иметь форму ниже для POST. Если пользователь вводит список, это создает ненужную сложность.     

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