RESTful дизайн - как смоделировать вложения объекта - PullRequest
Новая
       26

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

6 голосов
/ 08 октября 2009

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

Мне было интересно, как мне его смоделировать РЕСТАЛЬНО

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

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

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

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

  • GET, тип содержимого: mime multi-part на http://my -app / дефекты / {id} / attachments вернет вложения дефекта в мульти сообщение (двоичные данные и метаданные XML в целом)

  • POST, тип контента: XML для http://my -app / дефектов / {id} / attachments создаст новое вложение, только метаданные без вложенного файла ( тогда пользователь должен отправить запрос PUT с двоичными данными)

  • POST, тип контента: mime \ multi-part on http://my -app / дефекты / {id} / attachments создаст вложение, клиент может отправлять как метаданные, так и сам файл за одну поездку

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

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

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

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

  • POST, тип контента: XML на http://my -app / дефекты / {id} / attachments создаст новое вложение, только метаданные без вложенного файла (затем пользователь должен отправить запрос PUT с двоичными данными)

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

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

РЕДАКТИРОВАТЬ: Я проверил Загрузка мерцания API REST . Похоже, они используют сообщения, состоящие из нескольких частей, для включения атрибутов фото и фото.

Ответы [ 2 ]

3 голосов
/ 08 октября 2009

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

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

2 голосов
/ 08 октября 2009

Не управляйте метаданными отдельно. Действие из двух частей побеждает точку ОТДЫХА.

Как правило, один плавный GET / POST / PUT / DELETE с одной - относительно сложной полезной нагрузкой.

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

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

...