REST API的GET方法如何安全传递大参数（如订阅收据）？

问题背景 #

现有接口为 GET /api/available-plans/{provider-id}，其中{provider-id}可取"google"或"apple"。但在Apple订阅场景中，可用计划的部分属性依赖用户已订阅状态，需要上传用户的bundle receipt做分析——而收据数据量可达数十KB甚至超100KB，远超出URL参数的安全长度限制，无法直接通过URL传递。

以下是几种可行的替代方案：

• 带临时令牌的两步请求
  先调用一个轻量的POST接口提交完整收据数据，服务器验证后生成一个短期有效的临时令牌（比如5分钟有效期）返回给客户端。之后客户端用这个令牌作为参数调用原GET接口：GET /api/available-plans/apple?token=xxx。服务器通过令牌关联之前存储的收据数据，完成分析后返回可用计划。这种方式既保留了GET请求的语义，令牌体积小也适合URL传递，服务器还能通过自动过期机制清理临时数据，减少存储压力。

• HTTP Header+异步数据传输
  客户端先对收据数据做哈希（比如SHA-256）生成摘要，用服务器公钥加密后放在自定义HTTP Header（如X-Receipt-Digest）里。同时通过异步通道（比如WebSocket、后台静默POST）把完整收据发给服务器，服务器存储时关联这个加密摘要。客户端调用GET接口时带上该Header，服务器通过摘要找到对应的收据进行分析。这种方案不用修改原GET接口的URL结构，异步传输大体积数据也不会阻塞主请求流程。

• 灵活调整的查询型POST
  如果团队内部对REST规范的执行可以灵活处理，直接把接口改成POST /api/available-plans/apple，将收据数据放在请求体里，返回可用计划。需要明确约定这个POST接口是仅用于查询的非修改型请求，不会改变服务器状态。这种方式实现最简单，不用额外的令牌或异步逻辑，只要团队内部达成共识就不会有歧义。

• 客户端预解析关键信息
  针对Apple的bundle receipt，客户端可以本地解析出已订阅产品ID、过期时间等核心字段，只把这些小体积的关键数据通过URL参数或Header传给服务器。服务器基于这些信息计算可用计划，不用接收完整收据。这种方案完全避免大体积数据传输，性能最优，但需要客户端具备收据解析能力，同时要对关键信息做签名防止篡改。

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