REST API创建采购资源后，如何指定获取收据子资源？

这是个很常见的优化需求，毕竟没人愿意多做一次无意义的请求对吧？给你几个靠谱的RESTful方案，你可以根据自己的API架构和客户端场景来选：

方案1：利用Accept请求头指定返回格式 #

客户端在发送POST /purchase请求时，把Accept头设为application/pdf。服务器识别后，在创建采购资源成功的同时，直接生成并返回PDF收据，HTTP状态码保持201 Created，同时在Location响应头中仍然返回采购资源的URI（比如/purchase/123）。

• 优点：完全符合HTTP规范，不需要新增端点或修改请求体结构，对现有客户端无侵入（只要他们不强制指定Accept: application/json）
• 缺点：如果你的API原本就支持多种返回格式，需要确保逻辑能正确区分；另外要在文档里明确说明这个用法

示例请求：

POST /purchase HTTP/1.1
Host: your-api.com
Content-Type: application/json
Accept: application/pdf

{
  "amount": 100,
  "item": "Laptop"
}

方案2：在请求体中添加可选参数 #

允许客户端在POST请求的JSON体中加入一个可选字段（比如return_receipt: true），服务器识别到这个参数后，返回PDF收据而非默认的采购资源JSON。同样保持201 Created状态码和Location头。

• 优点：逻辑直观，客户端开发者一看就懂，不需要理解HTTP头的细节
• 缺点：需要更新采购资源的请求体Schema，不过设为可选字段的话，不会影响现有客户端

示例请求：

POST /purchase HTTP/1.1
Host: your-api.com
Content-Type: application/json

{
  "amount": 100,
  "item": "Laptop",
  "return_receipt": true
}

方案3：使用HTTP 303重定向 #

服务器在处理POST /purchase成功后，返回303 See Other状态码，并将Location响应头设为收据的URI（比如/purchase/123/receipt）。支持自动重定向的客户端会自动发起GET请求获取PDF，不需要用户额外操作。

• 优点：利用HTTP标准机制，服务器端逻辑改动小
• 缺点：部分客户端（尤其是自定义的后端客户端）可能不会自动处理303重定向；如果客户端同时需要采购资源的JSON数据，这个方案就不适用了

示例响应：

HTTP/1.1 303 See Other
Location: /purchase/123/receipt

方案4：新增专用端点（不推荐） #

创建一个新的端点比如POST /purchase-with-receipt，这个端点的逻辑是创建采购资源后直接返回PDF收据。

• 优点：逻辑完全独立，不会影响原接口
• 缺点：不符合REST的单一资源原则，增加了API的维护成本，客户端需要记住多个相似端点

通用注意事项 #

不管选哪种方案，都要：

• 在API文档中清晰说明这个功能的用法
• 返回PDF时，正确设置Content-Type: application/pdf响应头
• 始终在响应中包含采购资源的Location头，方便客户端后续对采购资源进行操作

内容的提问来源于stack exchange，提问作者Victor