JS请求返回415错误如何解决？

Question

在使用JavaScript发起POST请求时，常遇到服务器返回415 Unsupported Media Type错误。该问题通常出现在前端发送JSON数据但未正确设置请求头的场景中。浏览器默认不会自动设置Content-Type，若未手动指定为application/json，后端将无法识别请求体格式，从而拒绝请求。解决方法是在请求头中显式添加Content-Type: 'application/json'，并确保请求体通过JSON.stringify()序列化。此问题多见于使用fetch或XMLHttpRequest时配置不当的情况，是前后端数据交互中的典型误区之一。

Answer 1

JavaScript发起POST请求时415错误的深度解析与实战方案

1. 问题现象：415 Unsupported Media Type 错误初探

在前端开发中，使用 JavaScript 发起 POST 请求是常见操作。然而，开发者常会遇到服务器返回 415 Unsupported Media Type 的 HTTP 状态码。该状态码表示服务器拒绝处理当前请求，因为请求实体的媒体类型不被支持。

典型场景如下：

• 前端尝试发送 JSON 数据至后端 API 接口
• 请求体为对象格式，但未进行序列化
• 未设置正确的 Content-Type 请求头
• 后端期望接收 application/json，但实际接收到的是 text/plain 或无类型数据

浏览器不会自动推断内容类型，因此必须由开发者显式声明。

2. 技术原理：Content-Type 与 MIME 类型的作用机制

Content-Type 是 HTTP 请求头中的关键字段，用于告知服务器请求体的数据格式。服务器依赖此头部决定如何解析传入的数据流。

Content-Type 值	用途说明	常见序列化方式
application/json	传输结构化 JSON 数据	JSON.stringify(data)
application/x-www-form-urlencoded	传统表单提交格式	new URLSearchParams(data)
multipart/form-data	文件上传或混合数据	FormData 对象
text/plain	纯文本内容	直接字符串传递

若未正确设置 Content-Type: application/json，即使数据已序列化，后端也可能按默认编码处理，导致解析失败。

3. 常见实现方式对比分析

以下是三种主流 JavaScript 请求方式对 Content-Type 的处理差异：

1. fetch API - 需手动设置 headers 和 body 序列化
2. XMLHttpRequest - 通过 setRequestHeader 显式指定类型
3. Axios - 自动设置部分 header，但仍需注意配置细节

4. 实战代码示例：正确配置 POST 请求

4.1 使用 fetch 发送 JSON 请求

const response = await fetch('/api/user', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
    },
    body: JSON.stringify({
        name: 'John Doe',
        email: '[e-mail]'
    })
});
    

4.2 使用 XMLHttpRequest

const xhr = new XMLHttpRequest();
xhr.open('POST', '/api/user');
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.send(JSON.stringify({
    name: 'Jane Smith',
    age: 30
}));
    

4.3 使用 Axios（自动设置 Content-Type）

axios.post('/api/user', {
    name: 'Bob Lee',
    role: 'developer'
})
.then(res => console.log(res.data));
    

5. 调试流程图：定位 415 错误根源

graph TD
            A[发起 POST 请求] --> B{是否设置 Content-Type?}
            B -- 否 --> C[添加 Content-Type: application/json]
            B -- 是 --> D{请求体是否 JSON.stringify?}
            D -- 否 --> E[序列化请求体]
            D -- 是 --> F[检查后端路由配置]
            F --> G{是否接受 application/json?}
            G -- 否 --> H[调整后端中间件如 express.json()]
            G -- 是 --> I[成功响应 2xx]
            C --> J[重试请求]
            E --> J
            J --> K{仍返回 415?}
            K -- 是 --> L[查看网络面板请求头与负载]
            K -- 否 --> I

6. 深层排查：跨框架与环境的影响因素

某些现代框架（如 Next.js、Nuxt.js）的服务端接口可能默认不启用 JSON 解析中间件。例如，在 Express 中需显式引入：

app.use(express.json()); // 解析 application/json
app.use(express.urlencoded({ extended: true })); // 解析 x-www-form-urlencoded
    

若缺失 express.json()，即便前端正确发送 JSON，服务端也无法识别，最终返回 415。

7. 工程化建议：构建可复用的请求封装层

为避免重复错误，推荐封装统一的 HTTP 客户端：

function postJson(url, data) {
    return fetch(url, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
        },
        body: JSON.stringify(data)
    });
}
// 使用
postJson('/api/login', { username: 'admin', pwd: '123' });
    

此类抽象可降低团队出错概率，提升代码一致性。

8. 浏览器 DevTools 分析技巧

利用 Chrome 开发者工具 Network 面板进行诊断：

• 选择对应请求条目
• 查看 Headers 子标签中的 Request Headers
• 确认 Content-Type: application/json 是否存在
• 检查 Request Payload 是否为合法 JSON 字符串
• 比对 Response 内容以判断是否为后端明确拒绝

这些步骤能快速验证问题是否源于前端配置疏漏。

9. 安全与兼容性考量

虽然设置 Content-Type 是必要操作，但也应注意：

• 避免在非 JSON 请求中错误设置该头，引发反向问题
• 在 CORS 场景下，预检请求（OPTIONS）可能因自定义头触发，需后端配合允许
• 某些老旧系统可能限制特定 MIME 类型，需做降级兼容

合理设计请求策略有助于提高系统的健壮性和可维护性。

10. 总结性思考：从单一错误看前后端协作规范

415 错误表面是技术配置问题，实则反映前后端契约不清。理想情况下，API 文档应明确要求：

• 支持的 Content-Type 类型
• 请求体结构定义
• 错误码语义说明
• 示例请求/响应样本

建立标准化通信协议，才能从根本上减少此类“低级”但高频的问题发生。