Стратегия RESTful публикации многих объектов

Question

Я все еще нахожусь в процессе освоения дел в ОТДЫХ.

В моей ситуации клиентское программное обеспечение будет взаимодействовать с сервисом RESTful. В редких случаях клиент загружает всю свою базу данных сущностей (каждая сущность сериализуется примерно в 5-килобайтный фрагмент xml).

Возможно, я ошибаюсь, но правильная стратегия RESTful, похоже, состоит в том, чтобы циклически проходить через каждую сущность и индивидуально размещать каждую. Однако, вероятно, таких объектов может быть десятки тысяч, и так много быстрых POST не кажутся кошерными.

В этой ситуации создается впечатление, что упаковка всех сущностей в одно большое xml-представление нарушит RESTful-способ работы, но это также избавит от необходимости тысяч POST.

Существует ли стандартная практика для достижения этой цели? Заранее спасибо!

Answer 1

Не понимаю, почему «Пакет сущностей» нельзя считать ресурсом. Транзакционные записи, безусловно, могут рассматривать транзакцию базы данных как ресурс. Я признаю, что не читал диссертацию Филдинга, но не понимаю, как объединение нескольких ресурсов в одно представление лишает законной силы REST.

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

Он также используется в другом направлении. Когда клиент получает результаты поиска с сервера, сервер может обернуть их внутри ресурса результатов, чтобы клиент мог просто получить этот один ресурс вместо нескольких отдельных.

Так что я бы сказал, что оборачивание этих маленьких 5-килобайтных ресурсов в больший ресурс коллекции может считаться RESTful и, вероятно, именно так вам и следует.

Answer 2

Здесь есть как минимум две проблемы, которые мешают вам быть RESTful.

1. Каждый ресурс должен быть идентифицирован по URI. Работа с ресурсом означает, что вы должны вызвать URI с помощью HTTP-вызова. Следовательно, вы не можете вызывать несколько действий в нескольких ресурсах всего за один HTTP-вызов.

2. Ресурсы идентифицируются существительными и представляют сущности. Это означает, что для вставки «Сотрудник» и «Автомобиль» необходимо вызвать два разных ресурса для каждого из соответствующих объектов.

Итак, суммируя, вы не можете использовать чисто RESTful подход. Тем не менее, REST разработан для того, чтобы помогать путем соглашений, а не стеснять вас. Лучшее решение для вас - создать собственное действие, которое делает то, что вам нужно.

Кроме того, вы можете создать универсальную сущность-обертку с INSERT, UPDATE и другими действиями, которые выполняют операции с каплями разнородных данных как XML. Однако это подорвет ваши другие конечные точки, потому что теперь становится возможным вставить запись Car через универсальную оболочку и через /Car/ URI.

Не зная о ваших реальных требованиях, я бы посоветовал вам не раскрывать эту функцию специально через REST. За кулисами вы все равно могли бы вызывать свои методы действия INSERT в различных контроллерах, если разбили входящую коллекцию, если разрозненные объекты.

Answer 3

Пока большая обертка имеет допустимый тип носителя, то можно рассматривать его как единый ресурс. Выяснить, каким будет этот медиа-тип, - сложная часть.

Answer 4

Ничто не мешает вам создавать дополнительные ресурсы после добавления, то есть опубликовать ресурс, представляющий собой список X, на ресурс, представляющий собой список X, с помощью POST.

Затем вы отправите обратно 201, созданный со списком URIS всех созданных ресурсов. Опять же, все это вполне допустимо.

То, что вы теряете, - это видимость посредникам после PUT, которая мешает им кэшировать или изменять конкретный ресурс по определенному URI. Хотя умный посредник будет обрабатывать 201 для целей кэширования.

И наличие одного не мешает тому, чтобы каждый созданный ресурс имел свой собственный URI после создания (после POST) и включал PUT / DELETE на этих ресурсах. Или комбинация.