Ao desenvolver aplicações web e APIs REST, é essencial entender como os dados são enviados nas requisições HTTP. Um dos componentes fundamentais para isso é o cabeçalho Content-Type, que informa ao servidor (ou cliente) qual o formato dos dados presentes no corpo da requisição.

Neste artigo, vamos explorar os principais tipos de Content-Type, explicando quando utilizar cada um, suas estruturas, exemplos práticos, vantagens, desvantagens e dicas úteis para fazer a escolha correta em seu projeto.

O que é o Content-Type?

O cabeçalho Content-Type faz parte da especificação HTTP e indica o tipo de mídia (MIME type) do corpo da requisição ou resposta. Ele é essencial para que o servidor saiba como interpretar os dados recebidos e respondê-los adequadamente.

				
					POST /api/usuario HTTP/1.1
Content-Type: application/json

{
  "nome": "João",
  "email": "joaonwe@nwe.com"
}

Ao definir “Content-Type: application/json”, estamos informando explicitamente que os dados enviados no corpo da requisição estão estruturados como um objeto JSON. Isso é fundamental para que o servidor saiba como processar essas informações, convertendo-as corretamente para um objeto ou estrutura interna apropriada.

Sem esse cabeçalho, o servidor pode interpretar o conteúdo de forma incorreta, ocasionando erros de leitura, falhas na conversão dos dados ou respostas inesperadas.

application/json

O “Content-Type: application/json” é o mais utilizado atualmente em APIs REST. Ele informa que os dados no corpo da requisição estão estruturados em formato JSON (JavaScript Object Notation), um formato leve e de fácil leitura, usado para representar objetos, arrays, strings, números e valores booleanos.

Esse tipo de conteúdo é ideal quando se está trabalhando com serviços web modernos, pois quase todas as linguagens de programação oferecem suporte nativo para leitura e escrita de JSON. É usado tanto para enviar quanto para receber dados estruturados, como ao criar ou atualizar um recurso em uma API.

Vamos supor que você esteja enviando uma requisição para criar um novo post em uma API. Veja como isso é feito em C# com “HttpClient”:

				
					var httpClient = new HttpClient();
var url = "https://jsonplaceholder.typicode.com/posts";

var novoPost = new
{
    title = "Tipos de envio de requisições HTTP (Content-Type)",
    body = "Aprendendo sobre tipos de  requisições na  NWE",
    userId = 1
};

var json = JsonSerializer.Serialize(novoPost);

var content = new StringContent(json, Encoding.UTF8, "application/json");

var response = await httpClient.PostAsync(url, content);

No código acima, inicializamos uma instância do “HttpClient” e criamos um objeto anônimo que representa os dados a serem enviados na requisição. Em seguida, utilizamos o “JsonSerializer” para converter esse objeto em uma string JSON. Para compor o corpo da requisição, criamos um “StringContent”, onde informamos o conteúdo serializado, a codificação (UTF-8) e o cabeçalho “Content-Type”, que neste caso é “application/json”.

Vantagens:

  • Formato leve e de fácil leitura para humanos e máquinas.
  • Suporte nativo na maioria das linguagens de programação.
  • Ideal para APIs RESTful modernas.
  • Boa integração com frameworks e bibliotecas front-end (como Angular, React, Vue).
  • Permite aninhamento de estruturas (objetos e arrays).

Desvantagens:

  • Não é adequado para envio de arquivos binários (como imagens).
  • Pode exigir validação e serialização manual em sistemas que não têm suporte automático.

multipart/form-data

O “Content-Type: multipart/form-data” é utilizado principalmente quando precisamos enviar arquivos ou dados mistos (como textos e arquivos) em uma única requisição HTTP — especialmente formulários HTML que incluem input “type=”file””.

Esse tipo de conteúdo divide o corpo da requisição em várias partes, separadas por um delimitador (chamado boundary). Cada parte representa um campo ou arquivo enviado, permitindo que tipos diferentes de dados sejam incluídos na mesma requisição.

Para entendermos o seu funcionamento, vamos simular o envio de um formulário com nome e uma imagem usando “HttpClient”, e testaremos na URL pública “https://httpbin.org/post” que retorna exatamente o que foi recebido (útil para inspecionar o resultado).

				
					var httpClient = new HttpClient();
var url = "https://httpbin.org/post";

var caminhoArquivo = "@"C:\Users\Pictures\foto.png";
using var fileStream = File.OpenRead(caminhoArquivo);

using var form = new MultipartFormDataContent();

form.Add(new StringContent("João da Silva"), "nome");

form.Add(new StreamContent(fileStream), "arquivo", "foto.png");

var response = await httpClient.PostAsync(url, form);
var resposta = await response.Content.ReadAsStringAsync();

Primeiro, abrimos o arquivo “foto.png” em modo leitura e criamos um objeto “MultipartFormDataContent”, que é responsável por estruturar corretamente as partes da requisição. Em seguida, adicionamos um campo de texto chamado “nome” com o valor “João da Silva” e um campo de arquivo chamado “arquivo”, onde enviamos o conteúdo binário da imagem. A chamada “httpClient.PostAsync(url, form)” envia os dados para a URL especificada. 

Ao lermos a resposta podemos ver que nos foi retornado o arquivo enviado em  base64  e o texto enviado.

Vantagens:
  • Permite o envio de arquivos binários (imagens, PDFs etc.) e campos de texto simultaneamente.
  • Amplamente utilizado em formulários HTML que envolvem upload de arquivos.
  • Bem suportado por navegadores e frameworks.
Desvantagens:
  • Mais complexo para serializar/deserializar do que JSON ou x-www-form-urlencoded.
  • Requisições maiores e menos eficientes em termos de tamanho do payload.

application/x-www-form-urlencoded

O “Content-Type: application/x-www-form-urlencoded” é um dos formatos mais antigos e ainda amplamente utilizados para o envio de dados em requisições HTTP — especialmente em formulários HTML simples.

Nesse formato, os dados são codificados como pares “chave=valor”, separados por &. Caracteres especiais são escapados com encoding URL (ex: espaço vira %20 ou +). Esse conteúdo é colocado geralmente no corpo da requisição POST.

				
					var httpClient = new HttpClient();
var url = "https://httpbin.org/post";

var formData = new Dictionary<string, string>
{
    { "usuario", "joao" },
    { "idade", "19" }
};

var content = new FormUrlEncodedContent(formData);

var response = await httpClient.PostAsync(url, content);
var resposta = await response.Content.ReadAsStringAsync();

Primeiro, criamos um dicionário com os dados que queremos enviar no corpo da requisição — no caso, um campo “usuario” com valor “joao” e um campo “idade” com valor “19”. Em seguida, utilizamos a classe “FormUrlEncodedContent” para codificar esses dados no formato “application/x-www-form-urlencoded”, que os transforma em uma string como “usuario=joao&senha=123456”.

Vantagens:

  • Leve e fácil de gerar (ideal para formulários simples).
  • Compatível com todos os navegadores e fácil de ser manipulado com HttpClient ou jQuery.
  • Simples de integrar em sistemas legados ou com baixa complexidade.

Desvantagens:

  • Não suporta envio de arquivos.
  • Dados codificados manualmente (ex: espaços, acentos), o que pode causar erros se não for bem tratado.
  • Estrutura plana — não permite aninhamento de objetos ou arrays com facilidade.

application/xml

O “Content-Type: application/xml” é utilizado quando queremos enviar dados estruturados em formato XML. Esse formato é comum em integrações com sistemas legados, serviços SOAP ou APIs que adotam XML como padrão de comunicação.

No XML, os dados são organizados em elementos hierárquicos com marcações de abertura e fechamento, o que facilita a validação e o transporte de dados com estrutura complexa. É necessário informar esse Content-Type para que o servidor saiba como interpretar o corpo da requisição.

				
					var httpClient = new HttpClient();
var url = "https://httpbin.org/post";

var xml = @"<usuario>
                <nome>João da Silva</nome>
                <email>joao@email.com</email>
            </usuario>";

var content = new StringContent(xml, System.Text.Encoding.UTF8, "application/xml");

var response = await httpClient.PostAsync(url, content);
var resposta = await response.Content.ReadAsStringAsync();

No código acima, nós criamos uma string contendo o conteúdo XML que será enviado no corpo da requisição — com os campos <nome> e <email> encapsulados dentro do elemento <usuario>. Em seguida, utilizamos a classe “StringContent”, definindo o conteúdo como texto e informando explicitamente o “Content-Type” como “application/xml”.

Vantagens:

  • Estrutura rica, com suporte a atributos, namespaces e validação via DTD/XSD.
  • Recomendado em integrações com sistemas legados ou APIs baseadas em SOAP.
  • Mais robusto para domínios onde a estrutura dos dados precisa ser fortemente validada.

Desvantagens:

  • Verboso e maior em tamanho comparado ao JSON.
  • Mais difícil de manipular em linguagens modernas (como JavaScript).
  • Popularidade em queda nas APIs modernas, que preferem JSON por simplicidade.

Acelere a sua carreira conosco!

Se você é Desenvolvedor .NET Júnior e quer acelerar sua carreira até nível Pleno com salário de R$7k+, ou mesmo busca a primeira vaga, conheça a Mentoria .NET Start: Clique aqui

Se é Desenvolvedor .NET Pleno ou Sênior e quer virar referência técnica em sua equipe e mercado, com salário de R$10k+, conheça a Mentoria .NET Expert: Clique aqui

Conclusão

Escolher o “Content-Type” correto ao enviar dados em uma requisição HTTP não é apenas uma questão técnica, mas uma decisão que afeta diretamente a compatibilidade, a segurança e a eficiência da comunicação entre cliente e servidor. Cada tipo abordado tem seus próprios casos de uso ideais, e compreender suas diferenças é essencial para o desenvolvimento de APIs robustas e interoperáveis.