REST полезно создавать сложные объекты в одном POST?

Question

У меня есть форма, где пользователи создают личные записи. Каждый человек может иметь несколько атрибутов - рост, вес и т. Д. Но они также могут иметь списки связанных данных, таких как интересы, любимые фильмы и т. Д.

У меня есть одна форма, где собираются все эти данные. Мне кажется, что я должен отправить все эти данные в одном запросе. Но разве это RESTful? Мое чтение предполагает, что интересы, любимые фильмы и другие списки должны быть добавлены в отдельных запросах POST. Но я не думаю, что это имеет смысл, потому что один из них может потерпеть неудачу, и тогда будет частичная вставка Человека, и он может пропустить их интересы или любимые фильмы.

Answer 1

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

Если ваши пользовательские данные зависят от пользователя (т. Е. «Отличной» строки, например, атрибута, такого как строка, представляющая (не проверенное) имя фильма), то они должны быть включены в создание POST пользовательского представления; однако, если данные не зависят от пользователя (где данные могут быть адресованы независимо от пользователя, например, ссылка, такая как фильм из набора фильмов), они должны быть добавлены независимо.

Причина этого заключается в том, что добавление ссылки в сочетании с исходным POST подразумевает транзакционность; то есть, если другой пользователь удаляет ссылку на фильм для «любимого» фильма между тем моментом, когда он выбран на клиенте, и когда проходит POST, добавление пользователя (должно быть в соответствии с этим дизайном) завершится неудачно, тогда как если «любимый» фильм не является ассоциативным, а является просто атрибутом, в котором нет ничего, на чем можно ошибиться (атрибуты (предположительно) не могут быть аннулированы третьей стороной).

И снова, это в значительной степени соответствует вашим конкретным потребностям, но я не согласен с частичной вставкой и указанием сбоев. Правильный способ обработки такого рода вещей, если вы действительно хотите запретить частичные вставки, это просто реализовать транзакции на стороне сервера; это единственный способ по-настоящему справиться с ситуацией, когда критический связанный ресурс удаляется в середине процесса.

Answer 2

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

Думайте о ресурсах в REST очень широко. Они могут отображать один в один со строками базы данных, но они не обязаны. Адресуемый ресурс может встраивать другие адресуемые ресурсы или включать ссылки на них. Пока вы соблюдаете свое представление и семантику операций базового протокола (т. Е. HTTP GET POST PUT и т. Д.), REST ничего не может сказать о других соображениях дизайна, которые могут сделать вашу жизнь проще или сложнее.

Answer 3

Я не думаю, что есть проблема с добавлением всех данных в одном запросе, если они неотъемлемо связаны с основным ресурсом (т. Е. Человеком в вашем случае). Если интерес, фав. фильмы и т. д. являются собственными ресурсами, с ними также следует обращаться.