У HTTP є два способи розміщення даних POST: application/x-www-form-urlencodedі multipart/form-data. Я розумію, що більшість браузерів можуть завантажувати файли, лише якщо multipart/form-dataвони використовуються. Чи є якісь додаткові вказівки щодо використання одного з типів кодування в контексті API (браузер не бере участь)? Це може, наприклад, базуватися на:

• розмір даних
• існування символів, що не належать до ASCII
• існування на (некодованих) двійкових даних
• необхідність передачі додаткових даних (наприклад, ім'я файлу)

Я в основному не знайшов офіційних вказівок в Інтернеті щодо використання різних типів вмісту до цих пір.

TL; DR

Підсумок; якщо у вас є бінарні (не алфавітно-цифрові) дані (або значне корисне навантаження) для передачі, використовуйте multipart/form-data. В іншому випадку використовуйте application/x-www-form-urlencoded.

Згадані вами типи MIME - це два Content-Typeзаголовки для HTTP POST-запитів, які повинні підтримувати користувальницькі агенти (браузери). Мета обох цих типів запитів - надіслати на сервер список пар імен / значень. Залежно від типу та кількості даних, що передаються, один із методів буде більш ефективним, ніж інший. Щоб зрозуміти чому, ви повинні подивитися, що кожен робить під прикриттями.

Тому application/x-www-form-urlencoded, що тіло повідомлення HTTP, надіслане серверу, по суті є однією гігантською рядком запиту - пари імен / значень розділені амперсандом ( &), а імена відокремлені від значень символом рівним ( =). Прикладом цього може бути: 

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

Відповідно до специфікації :

[Зарезервовані та] не алфавітно-цифрові символи замінюються на "% HH", знак відсотка та дві шістнадцяткові цифри, що представляють ASCII код символу

Це означає, що для кожного не алфавітно-цифрового байта, який існує в одному з наших значень, для його представлення потрібно три байти. У великих бінарних файлах утроєне корисне навантаження буде дуже неефективним.

Ось де це multipart/form-dataприходить. При такому способі передачі пар імен / значень кожна пара представлена ​​як "частина" у повідомленні MIME (як описано в інших відповідях). Частини розділені певною межею рядка (вибрано спеціально таким чином, щоб ця гранична рядок не виникала в жодному з корисних навантажень "значення"). Кожна частина має власний набір MIME заголовків, як Content-Type, зокрема Content-Disposition, які можуть дати кожній частині її "ім'я". Елемент значення кожної пари імен / значень є корисним завантаженням кожної частини повідомлення MIME. Специфікація MIME надає нам більше варіантів при поданні значення корисного навантаження - ми можемо вибрати більш ефективне кодування бінарних даних для збереження пропускної здатності (наприклад, база 64 або навіть необроблена двійкова).

Чому б не використовувати multipart/form-dataвесь час? Що стосується коротких буквено-цифрових значень (як і більшість веб-форм), накладні витрати на додавання всіх заголовків MIME значно перевищують будь-яку економію від більш ефективного двійкового кодування.

ЧИТАТИ ОСТАННЯ ПЕРШОГО ПАРА ТУТ!

Я знаю, що це на 3 роки занадто пізно, але відповідь Метта (прийнята) не є повною, і врешті-решт у вас виникнуть проблеми. Ключовим тут є те, що якщо ви вирішили використовувати multipart/form-data, межа не повинна відображатися у файлових даних, які сервер врешті отримує.

Це не проблема application/x-www-form-urlencoded, тому що немає меж. x-www-form-urlencodedтакож завжди може обробляти двійкові дані, за допомогою простого доцільного перетворення одного довільного байта в три 7BITбайти. Неефективна, але вона працює (зауважте, що коментар про неможливість надсилання імен файлів, а також бінарних даних невірний; ви просто надсилаєте їх як іншу пару ключів / значень).

Проблема multipart/form-dataполягає в тому, що розділовий пристрій не повинен бути присутнім у файлових даних (див. RFC 2388 ; розділ 5.2, також містить досить кульгавий привід для відсутності належного сукупного типу MIME, що дозволяє уникнути цієї проблеми).

Отже, на перший погляд, не multipart/form-dataмає жодної цінності у будь-якому завантаженні файлів, бінарному чи іншому. Якщо ви не вибрали кордон правильно, то з часом у вас виникне проблема, чи ви надсилаєте звичайний текст чи необроблений бінарний файл - сервер знайде межу в неправильному місці, а ваш файл буде усічений або POST не вдасться.

Ключ полягає у виборі кодування та межі, щоб вибрані граничні символи не могли відображатися у кодованому виході. Одне просте рішення - це використання base64( не використовуйте сирі двійкові). У base64 3 довільні байти кодуються чотирма 7-бітовими символами, де набір вихідних символів [A-Za-z0-9+/=](тобто буквено-цифрові символи, '+', '/' або '='). =є окремим випадком і може з’являтися лише в кінці кодованого виводу, як одинарний, =або як подвійний ==. Тепер виберіть свою межу як 7-бітну рядок ASCII, яка не може відображатися у base64висновку. Багато варіантів, які ви бачите в мережі, не проходять цей тест - MDN формує документинаприклад, використовувати "blob" в якості межі при надсиланні двійкових даних - не добре. Однак щось на кшталт "! Blob!" ніколи не з’явиться у base64виході.

Я не думаю, що HTTP обмежений POST у багаточастинному або x-www-form-urlencoded. Content-Type заголовка ортогональна методу HTTP POST (ви можете заповнити тип MIME , який підходить вам). Це також стосується типових веб-представлень на базі HTML-репрезентації (наприклад, корисна навантаження json стала дуже популярною для передачі корисного навантаження для запитів ajax).

Щодо Restful API через HTTP, найпопулярніші типи контенту, з якими я зв’язався, це application / xml та application / json.

додаток / xml:

• розмір даних: XML дуже багатослівний, але зазвичай це не проблема, коли використовується стиснення та думка, що випадок доступу до запису (наприклад, через POST або PUT) набагато рідше, ніж доступ для читання (у багатьох випадках це <3% усього трафіку) ). Рідко трапляються випадки, коли мені доводилося оптимізувати ефективність запису
• існування символів не-ascii: ви можете використовувати utf-8 як кодування в XML
• існування двійкових даних: потрібно було б використовувати кодування base64
• дані про ім’я файлу: це внутрішнє поле можна інкапсулювати в XML

додаток / json

• розмір даних: компактніший менше, ніж XML, нерухомий текст, але його можна стискати
• non-ascii chars: json is utf-8
• двійкові дані: base64 (також див. json-бінарне запитання )
• дані імені файлу: інкапсулювати як власний розділ поля всередині json

бінарні дані як власний ресурс

Я б спробував представити двійкові дані як власний актив / ресурс. Це додає ще один дзвінок, але декупаж краще виконувати. Приклади зображень:

POST /images
Content-type: multipart/mixed; boundary="xxxx" 
... multipart data

201 Created
Location: http://imageserver.org/../foo.jpg  

У наступних ресурсах ви можете просто вкласти бінарний ресурс як посилання:

<main-resource>
 ...
 <link href="http://imageserver.org/../foo.jpg"/>
</main-resource>

Я дуже згоден з тим, що сказав Мануель. Насправді його коментарі стосуються цієї URL-адреси ...

http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4

... де зазначено:

Тип вмісту "application / x-www-form-urlencoded" неефективний для надсилання великої кількості бінарних даних або тексту, що містить символи, що не містять ASCII. Тип вмісту "багаточастинні / форми-дані" слід використовувати для подання форм, що містять файли, не-ASCII дані та двійкові дані.

Однак для мене це зводиться до підтримки інструментів / рамок.

• З якими інструментами та рамками ви очікуєте, що ваші користувачі API будуватимуть свої додатки?
• Чи є у них рамки чи компоненти, якими вони можуть скористатися одним методом над іншим?

Якщо ви отримаєте чітке уявлення про своїх користувачів та як вони використовуватимуть ваш API, то це допоможе вам вирішити. Якщо ви завантажите файли важкими для своїх користувачів API, вони відійдуть, ви витратите багато часу на їх підтримку.

Вторинним для цього є підтримка, яку ви маєте для написання вашого API, і як легко розмістити один механізм завантаження над іншим.

Трохи підказки з мого боку для завантаження зображень полотна HTML5:

Я працюю над проектом для друкарні, і у мене виникли деякі проблеми через завантаження зображень на сервер, що надходили з canvasелемента HTML5 . Я боровся принаймні годину, і я не отримав цього, щоб правильно зберегти зображення на своєму сервері.

Одного разу я встановив contentTypeможливість мого виклику jQuery ajax, щоб application/x-www-form-urlencodedвсе пішло правильно, і кодовані базовими кодами дані були інтерпретовані правильно та успішно збережені як зображення.

Може, це комусь допомагає!

Якщо вам потрібно використовувати Content-Type = x-www-urlencoded-form, то НЕ використовуйте FormDataCollection як параметр: У asp.net Core 2+ FormDataCollection не має конструкторів за замовчуванням, які потрібні форматерам. Використовуйте замість IFormCollection:

 public IActionResult Search([FromForm]IFormCollection type)
    {
        return Ok();
    }