RESTful design - как моделировать вложения объекта

Question

Я пытаюсь смоделировать вложения объекта в REST.Допустим, дефектный объект может иметь несколько вложений, прикрепленных к нему.Каждое вложение имеет описание и некоторые другие свойства (последнее изменение, размер файла ...).Само вложение представляет собой файл в любом формате (jpeg, doc ...)

Мне было интересно, как мне следует это спокойно смоделировать

Я думал о следующих двух вариантах:

Первый подход (использование одного и того же ресурса, разные представления):

• GET , content-type:XML на http://my-app/defects/{id}/вложения вернет дефект метаданные вложений в формате XML (описание, последнее изменение, размер файла ...)

• GET , тип содержимого:gzip на http://my-app/defects/{id}/вложения вернет вложения дефекта в zip-файле

• GET , content-type: многосоставный mime на http://my-app/defects/{id}/вложения вернет вложения дефекта в виде сообщения, состоящего из нескольких частей (двоичные данные и метаданные XML в целом).

• СООБЩЕНИЕ, тип содержимого: XML на http://my-app/defects/{id}/вложения создаст новое вложение, только с метаданными, без прикрепленного файла (тогда пользователь должен отправить запрос PUT с двоичными данными)

• СООБЩЕНИЕ , тип содержимого: mime \ многосоставное на http://my-app/defects/{id}/вложения после создания вложения клиент может отправить как метаданные, так и сам файл за один цикл

Второй подход (отделите данные вложения от метаданных):

• GET , content-type:XML на http://my-app/defects/{id}/вложения вернет дефект метаданные вложений в формате XML (описание, последнее изменение, размер файла ...)

• GET , тип содержимого:gzip на http://my-app/defects/{id}/вложения/файлы вернет двоичные данные вложений дефекта в одном zip-файле

Создание нового вложения, первый вызов:

• СООБЩЕНИЕ, тип содержимого: XML на http://my-app/defects/{id}/вложения создаст новое вложение, только с метаданными, без прикрепленного файла (тогда пользователь должен отправить запрос PUT с двоичными данными)

Затем добавьте сами двоичные данные:

• СООБЩЕНИЕ , тип содержимого: mime \ многосоставное на http://my-app/defects/{id}/вложения/{id}/файл создаст файл вложения

---

С одной стороны, первый подход является более надежным и эффективным, поскольку клиент может создавать \ получать метаданные вложений и двоичные данные за один цикл.С другой стороны, я немного неохотно использую mime-составное представление, поскольку оно более громоздко в использовании и производстве.

Редактировать: Я проверил REST API для загрузки flicker.Похоже, что они используют сообщения из нескольких частей, включающие как фотографию, так и атрибуты фотографии.

Answer 1

Не управляйте метаданными отдельно.Действие, состоящее из двух частей, сводит на нет точку ПОКОЯ.

Обычно выполняется одно плавное ПОЛУЧЕНИЕ / ПУБЛИКАЦИЯ / РАЗМЕЩЕНИЕ / УДАЛЕНИЕ с одной - относительно - сложной полезной нагрузкой.

Тот факт, что это несколько базовых "объектов" в "таблицах", не имеет отношения к REST.

На уровне REST это всего лишь состояние одного сложного объекта, передаваемое с одним сообщением.

Answer 2

Большая часть этой проблемы уже была решена спецификацией Atom Pub.Видишь здесь

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