Создание связанных сущностей в REST api в Symfony

каков правильный способ создания сущности, которая будет связана с другими? Я не могу найти источник о том, как это должно быть сделано или как это делается в Symfony с FOSRestBundle bundle.

Справочная информация:

позволяет иметь entity Car с сущностями колеса.

как создать автомобиль с колесами в одном запросе?
url: foo.com/cars после
данные: {car:{name="porsche", wheels:[{name:"fr"}, {name:"fl"}] }}
Это правильный способ, как это сделать это? Я читал что-то о методах LINK и UNLINK http, но для этого нужно было бы отправить несколько запросов, чтобы создать все колеса, а затем связать их вместе.

как создать колесо с несколькими автомобилями?
url: foo.com/wheels после
данные: {wheel:{name="super wheel", cars:[{id:1}, {id:2}] }}
В этой ситуации, возможно, было бы целесообразно использовать Заголовок ссылки. Но после прочтения этой статья, это потребует разбора заголовков ссылок для всех сообщений и ставит, а также, что делает его дорогим и громоздким.

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

я написал автору упомянутой статьи. Вот его ответ:

Я думаю, вы можете отправить данные, содержащие как ваши колеса, так и автомобили в одном запросе. Самое главное здесь-быть прагматичным. Для построения API REST нет" четких " правил.

LINK / UNLINK полезны, когда ресурсы уже существуют, и вы хотите " связать" другими словами, вы хотите добавить между ними" отношение", например, дружбу для пользователей.

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

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

2 ответов


У нас была такая же дискуссия совсем недавно.

есть что сказать для ясности и чистой архитектуры, где вы отделяете наши ресурсы от отношений и так далее. Есть также что-то, что нужно сказать, чтобы не делать 1000 запросов и собирать вещи, которые принадлежат друг другу.

наше окончательное решение было очень похоже на ваше. Другим решением было бы никогда не включать отношения в ресурсы при их вставке и иметь отдельный API конечная точка для создания отношений (например, POST /cars/1/wheels/fl)

какой путь вы идете в основном зависит от вашей логики домена и требований приложения. Как только у вас появятся круговые отношения m:n, у вас будут большие проблемы с подходом, который вы (и мы) выбираете. Для более простых и иерархических отношений это отличный способ сделать это.


Как вы процитировали: "нет" четких"правил для построения REST APIs".

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

Я не говорю, что вы должны использовать свою точку зрения. Но я говорю : ваш API, ваши правила (это зависит от клиента, чтобы адаптироваться, но вы также должны думать как клиент, чтобы создать API).