LEIA PELO MENOS O PRIMEIRO PARÁGRAFO AQUI!

Isto não é um problema para application/x-www-form-urlencoded, porque não há limite. x-www-form-urlencoded também pode sempre lidar com dados binários, pelo simples expediente de virar um byte arbitrário em três bytes 7BIT. Ineficiente, mas funciona (e observe que o comentário sobre não ser capaz de enviar nomes de arquivos, bem como dados binários é incorreto; você apenas envia como outro par de chaves/valores).

O problema com multipart/form-data é que o separador de limites não deve estar presente nos dados do ficheiro (ver RFC2388; a secção 5.2 também inclui uma desculpa esfarrapada para não ter um tipo MIME agregado adequado que evite este problema).

Não me parece que o HTTP esteja limitado a publicar em multipart ou x-www-form-urlencoded. O cabeçalho do tipo de Conteúdo é ortogonal ao método de POST HTTP (poderá preencher o tipo MIME que lhe convém). Este é também o caso de webapps típicos baseados em representação HTML (por exemplo, JSON payload tornou-se muito popular para a transmissão de carga útil para pedidos ajax).

Em relação à API repousante sobre HTTP, os tipos de conteúdo mais populares com os quais entrei em contacto são a aplicação / xml e application / json.

Application / xml:

• tamanho dos dados: XML muito descritivo, mas geralmente não um problema quando se usa compressão e pensar que o caso de acesso de escrita (por exemplo, através de POST ou PUT) é muito mais raro do que o acesso de leitura (em muitos casos é
• existência de caracteres não-ascii: poderá usar o utf-8 como codificação em XML
• existência de dados binários: seria necessário usar o base64 codificação
• dados dos nomes dos ficheiros: poderá encapsular este campo interior em XML

Application / json

• tamanho dos dados: mais compacto menos aquele XML, texto à mesma, mas você pode comprimir
• caracteres não ascii: json is utf-8
• dados binários: base64 (ver também JSON-binary-question)
• dados do nome do ficheiro: encapsular como secção própria do campo dentro do json

Dados binários como recursos próprios

Eu tentaria representar dados binários como activo/recurso próprio. Adiciona outra chamada, mas decupla melhor as coisas. Exemplo de imagens:

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

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

Em recursos posteriores, você poderia simplesmente alinhar o recurso binário como link:

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

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

... que estabelece:

O tipo de conteúdo "application/x-www-form-urlencoded" is ineficiente para enviar grandes quantidades de dados binários ou texto que contenham caracteres não ASCII. O tipo de conteúdo "multipart / form-data" devem ser utilizados para a apresentação de formulários que contêm ficheiros, não-ASCII dado, e dados binários.

• que Ferramentas e enquadramentos faz você espere que seus usuários da API estejam construindo as aplicações deles?
Eles têm frameworks ou componentes que podem usar que favorecem um método sobre o outro?

Se você tiver uma ideia clara de seus usuários, e como eles vão fazer uso de sua API, então isso vai ajudá-lo a decidir. Se tornar o envio de ficheiros difícil para os utilizadores da API depois eles vão-se embora, de TI vais passar muito tempo a apoiá-los.

Secundário a isso seria o Suporte de ferramenta que você tem para escrever a sua API e como é fácil para você acomodar um mecanismo de upload sobre o outro.

Apenas uma pequena dica do meu lado para carregar os dados da imagem de tela do HTML5:

Estou a trabalhar num projecto para uma tipografia e tive alguns problemas devido ao envio de imagens para o servidor que vieram de um elemento HTML5 {[[0]}. Eu estava lutando por pelo menos uma hora e eu não consegui para salvar a imagem corretamente no meu servidor.

Se necessitar de utilizar o Content-Type=x-www-urlencoded-form então não utilize FormDataCollection como parâmetro: em asp.net Core 2+ FormDataCollection has no default constructors which is required by Formatters. Utilize a recolha de dados IFormCollection em vez disso:

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