Я пытаюсь смоделировать вложения объекта в REST. Допустим, к объекту дефекта может быть прикреплено несколько вложений. Каждое вложение имеет описание и некоторые другие свойства (последнее изменение, размер файла...). Сам вложение представляет собой файл любого формата (jpeg, doc...)
Мне было интересно, как мне смоделировать его RESTful
Я думал о следующих двух вариантах:
Первый подход (с использованием одного и того же ресурса, разных представлений):
GET , тип содержимого:XML на http://my-app/defects/{id} /attachments вернет метаданные вложений дефекта в формате XML (описание, последнее изменение, размер файла...)
GET , тип содержимого:gzip на http://my-app/defects/{id} /attachments вернет вложения дефекта в zip-файле.
GET , content-type:mime multi-part on http://my-app/defects/ {id}/attachments вернет вложения дефекта в сообщении, состоящем из нескольких частей (все двоичные данные и метаданные XML).
POST, тип содержимого: XML на http://my-app/defects/{id} /attachments создаст новое вложение, только метаданные без прикрепленного файла (тогда пользователь должен отправить запрос PUT с двоичными данными)
POST , тип содержимого: mime\multi-part на http://my-app/defects/{id}/attachments создаст вложение, клиент может отправить как метаданные, так и сам файл за один раз
Второй подход (отделить данные вложения от метаданных):
GET , тип содержимого:XML на http://my-app/defects/{id} /attachments вернет метаданные вложений дефекта в формате XML (описание, последнее изменение, размер файла...)
GET , тип содержимого:gzip на http://my-app/defects/{id} /attachments/files вернет двоичные данные вложений дефекта в одном zip-архиве.
Создание нового вложения, первый вызов:
- POST, тип содержимого: XML на http://my-app/defects/{id} /attachments создаст новое вложение, только метаданные без прикрепленного файла (тогда пользователь должен отправить запрос PUT с двоичными данными)
Затем добавьте сами двоичные данные:
- POST , тип содержимого: mime\multi-part на http://my-app/defects/{id}/attachments/{id}/file создаст файл вложения
С одной стороны, первый подход более надежен и эффективен, поскольку клиент может создавать\получать метаданные вложений и двоичные данные за один цикл. С другой стороны, я немного неохотно использую представление mime-multipart, поскольку оно более громоздко для потребления и производства.
EDIT: я проверил REST API загрузки мерцания. Кажется, они используют сообщения, состоящие из нескольких частей, чтобы включать как фотографию, так и атрибуты фотографии.
