REST API - обработка файлов (т. е. изображений) - рекомендации

есть несколько решений, чтобы сделать:

1. о путь к ресурсу:

   • моделируйте изображение как ресурс самостоятельно:

     • вложенный в пользователя (/user/: id / image): связь между Пользователем и изображением выполняется неявно

     • в корневом пути (/image):

       • клиент несет ответственность за установление связи между изображением и пользователем, или;

       • если контекст безопасности предоставляется с запросом POST, используемым для создания образа, сервер может неявно установить связь между аутентифицированным пользователем и образом.

   • вставить изображение как часть пользователя

2. второе решение-это как представляем ресурс изображения:

   • как база 64 кодируется JSON полезная нагрузка
   • как составная полезная нагрузка

Это было бы мое решение трек:

• Я обычно предпочитаю дизайн по сравнению с производительностью, если для этого нет веских оснований. Это делает систему более ремонтопригодной и может быть более легко понято интеграторами.
• Итак, моя первая мысль-пойти на Base64 представление ресурса изображения, потому что он позволяет сохранить все JSON. Если вы выбрали эту опцию, вы можете моделировать путь к ресурсу по своему усмотрению.
  • если отношение между Пользователем и изображением составляет 1 к 1, я бы предпочел моделировать изображение как атрибут, особенно если оба набора данных обновляются одновременно. В любом другом случае вы можете свободно выбрать модель изображения либо как атрибут, обновляя его с помощью PUT или PATCH, либо как отдельный ресурс.
• если вы выберете составную полезную нагрузку, я буду вынужден моделировать изображение как ресурс самостоятельно, так что на другие ресурсы, в нашем случае на пользовательский ресурс, не влияет решение об использовании двоичного представления для изображения.

тогда возникает вопрос:есть ли влияние на производительность при выборе base64 против multipart?. Мы могли бы подумать, что обмен данными в составном формате должен быть более эффективным. Но в этой статье показывает, как мало оба представления отличаются по размеру.

мой выбор Base64:

• последовательное проектное решение
• незначительное влияние на производительность
• поскольку браузеры понимают URI данных (закодированные изображения base64), нет необходимости преобразовывать их, если клиент является браузером
• Я не буду голосовать за то, чтобы иметь его в качестве атрибута или автономного ресурса, это зависит от вашего проблемная область (которую я не знаю) и ваши личные предпочтения.

ваше второе решение, вероятно, самое правильное. Вы должны использовать спецификацию HTTP и mimetypes так, как они были предназначены, и загрузить файл через multipart/form-data. Что касается обработки отношений, я бы использовал этот процесс (имея в виду, что я знаю ноль о ваших предположениях или системном дизайне):

1. POST to /users создать объект пользователя.
2. POST изображение /images, убедившись, вернуть Location заголовок, где изображение может быть извлекается по спецификации HTTP.
3. PATCH до /users/carPhoto и присвоить ему идентификатор фотографии, приведенной в Location заголовок шага 2.

там нет простого решения. Каждый способ имеет свои плюсы и минусы . Но канонический способ использует первый вариант:multipart/form-data. Как руководство по рекомендации W3 говорит

тип контента "multipart / form-data" должен использоваться для отправки форм, содержащих файлы, данные, отличные от ASCII, и двоичные данные.

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

используя multipart/form-data вы придерживаетесь философии REST/http. Вы можете просмотреть ответ на аналогичный вопрос здесь.

другой вариант при смешивании альтернатив вы можете использовать multipart/form-data, но вместо того, чтобы отправлять каждое значение отдельно, вы можете отправить значение с именем полезная нагрузка с полезной нагрузкой json внутри него. (Я попробовал этот подход, используя ASP.NET WebAPI 2 и отлично работает).