HTTP请求中Content-Type与Accept头的作用有何区别？

Question

常见技术问题： 在HTTP通信中，`Content-Type` 和 `Accept` 都是关键的媒体类型协商头字段，但作用方向和语义常被混淆。`Content-Type` 用于**告知服务器当前请求体（如POST/PUT数据）的实际格式**（例如 `application/json` 或 `multipart/form-data`），是客户端对“我发了什么”的声明；而 `Accept` 是客户端向服务器表达的**期望响应格式偏好**（如 `Accept: application/json, text/html;q=0.9`），属于“我希望收到什么”的申明。二者不可互换：若POST请求携带JSON但漏设 `Content-Type: application/json`，后端可能无法正确解析；若未设置 `Accept`，服务器虽可按默认格式响应，但在API版本控制或内容协商（如HTML vs JSON API）场景下将丧失灵活性。此外，`Content-Type` 在请求中仅适用于含body的非GET/HEAD方法，而 `Accept` 可出现在任意请求中。理解这一单向职责划分（前者描述“输入”，后者声明“输出期望”），是设计健壮RESTful接口与调试406 Not Acceptable、415 Unsupported Media Type等状态码的基础。

Answer 1

```html

一、基础认知：HTTP媒体类型头字段的语义边界

在HTTP协议中，Content-Type 与 Accept 同属“内容协商”（Content Negotiation）机制的核心头字段，但二者职责严格单向隔离：Content-Type 描述请求体（request body）的**实际编码格式**，仅出现在含 payload 的请求（如 POST、PUT、PATCH）中；而 Accept 表达客户端对响应体（response body）的**首选表示形式**，可存在于任意请求方法（包括 GET、HEAD、DELETE）中。

二、典型误用场景与根因分析

• POST JSON 未设 Content-Type：前端使用 fetch(url, { method: 'POST', body: JSON.stringify(data) }) 却遗漏 headers: {'Content-Type': 'application/json'}，导致 Express/Koa/Spring Boot 等框架无法触发 JSON 解析中间件，req.body 为空或为原始字符串；
• 混淆 Accept 与 Content-Type 用途：在 GET 请求中错误设置 Content-Type: application/json（GET 无 body，该头非法且被多数服务端忽略）；
• API 版本协商失效：客户端期望 v2 JSON API，却未发送 Accept: application/vnd.myapi.v2+json，服务器只能返回默认 v1 响应，引发前端解析失败。

三、协议规范与状态码映射关系

头字段	方向	触发状态码	典型原因
Content-Type	Request → Server	415 Unsupported Media Type	服务器不支持该 MIME 类型（如接收 application/xml 但只实现 JSON 解析）
Accept	Request → Server	406 Not Acceptable	服务器有多种表示（HTML/JSON/XML），但无一匹配客户端 Accept 列表中的可接受类型

四、深度实践：从调试到工程化治理

对5年以上经验的工程师而言，问题已不止于“加个 header”，而需构建全链路保障：

1. 客户端 SDK 强约束：封装 HTTP 客户端时，默认为 JSON 请求注入 Content-Type: application/json，并提供 accept() 链式方法（如 api.get('/users').accept('application/vnd.api+json')）；
2. 网关层内容协商审计：在 API 网关（Kong/Tyk）配置策略，拒绝缺失 Content-Type 的非幂等请求，或自动重写 Accept 以适配后端能力；
3. OpenAPI 3.0 显式声明：在 requestBody.content 和 responses.200.content 中分别定义支持的 MIME 类型，驱动契约测试与 Mock 生成。

五、可视化流程：内容协商决策路径

flowchart TD
  A[Client Request] --> B{Has body?}
  B -->|Yes| C[Check Content-Type]
  B -->|No| D[Skip Content-Type validation]
  C --> E{Server supports this type?}
  E -->|No| F[415 Unsupported Media Type]
  E -->|Yes| G[Parse request body]
  A --> H[Check Accept header]
  H --> I{Can server produce any matching representation?}
  I -->|No| J[406 Not Acceptable]
  I -->|Yes| K[Select best match via q-factor & server capability]
  K --> L[Serialize response with Content-Type header]

六、进阶陷阱与反模式警示

• Accept 头的过度泛化：使用 Accept: */* 放弃协商权，导致无法区分浏览器直连（期望 HTML）与 JS 调用（期望 JSON），破坏 REST 架构的自描述性；
• Content-Type 的冗余设置：对 multipart/form-data 请求，手动拼接 boundary 值——应交由浏览器或 axios/fetch 自动处理；
• 服务端忽略 Accept 的“降级逻辑”：当客户端请求 application/hal+json 但服务端仅支持 application/json，应主动协商降级并返回 Content-Type: application/json + Vary: Accept，而非硬性报错。

```