Как восстановить отношения сущностей после сохранения?

тл;др

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

Подробнее

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

Итак, предполагая, что у вас есть существующий Category, выставленный через /categories/4711, вы можете опубликовать на своем сервере:

POST /products
{ links : [ { rel : "category", href : "/categories/4711" } ],
  // further product data
}

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

1. Определите свойства, которые необходимо заполнить, просмотрев типы отношений ссылок (например, свойство category здесь.
2. Извлечь идентификатор бэкэнда из заданного URI.
3. Используйте соответствующий репозиторий для поиска экземпляра связанной сущности.
4. Установите его на корневой объект

Итак, в вашем примере сводится к:

Product product = new Product();
// populate primitive properties
product.setCategory(categoryRepository.findOne(4711));
productRepository.save(product);

Просто отправьте что-то вроде этого на сервер:

POST /products
{ category : {
    id : 1, … },
  … 
}

является неоптимальным по многим причинам:

1. Вы хотите, чтобы поставщик постоянства неявно сохранял экземпляр Product и в то же время «признавал», что упоминаемый экземпляр Category (фактически состоящий только из идентификатора) не предназначен для сохранения, а обновляется данными уже существующего Category? Я бы сказал, что это немного магии.
2. По сути, вы накладываете структуру данных, которую вы используете для POST на сервер, на уровень сохраняемости, ожидая, что он будет прозрачно обрабатывать то, как вы решили выполнять POST. Это не ответственность уровня сохраняемости, а веб-уровня. Вся цель веб-уровня состоит в смягчении характеристик протокола на основе HTTP с использованием представлений и ссылок на серверную службу.