REST API DELETE 请求中敏感标识参数的最优处理方案探讨

方案优先级排序 #

最优方案优先度从高到低为：方案1 > 方案4 > 方案3 > 方案2

各方案专业判断 #

方案1：敏感ID放在DELETE请求体

调用形式为 DELETE /api/sometoken，请求体为 { "id": "<sensitiveid>" }

• 合规性：HTTP 1.1规范从未禁止DELETE请求携带请求体，仅部分老旧的反向代理、CDN、WAF会默认丢弃DELETE请求的Body，只要你的API调用链路没有这类不兼容组件，该方案完全符合规范。REST规范只要求请求语义明确，并没有强制要求所有资源标识必须放在URL中。
• 优势：实现成本几乎为0，完全规避敏感ID出现在URL被日志留存的风险，同时保留了DELETE方法的REST语义，不需要额外做映射、哈希计算逻辑。
• 注意点：接口文档需要明确标注DELETE接口需携带请求体参数，同步所有接入方的参数传输方式。

方案4：使用哈希ID作为路径参数

调用形式为 DELETE /api/sometoken/<hashofsensitiveid>

• 合规性：完全符合REST设计规范，资源路径指向明确，兼容所有网络组件。
• 优势：不存在DELETE请求体被丢弃的兼容性问题，只要使用加盐SHA-256哈希、取前16位以上字符，哈希碰撞概率可以忽略不计，也不会泄露原始敏感ID。
• 劣势：需要服务端额外存储敏感ID和哈希值的映射关系，或者每次请求时对库中所有对应敏感ID做实时哈希匹配，后者数据量大时会产生额外的计算开销，拉低接口性能。

方案3：使用抽象映射ID

• 优势：完全隔离敏感ID和对外暴露的标识，安全等级最高。
• 劣势：实现复杂度最高，需要额外维护抽象ID和敏感ID的映射关系，调用方需要多发起一次GET查询请求，调用链路更长、故障点更多，仅适合对安全等级要求极高的特殊场景。

方案2：改用POST请求承载删除操作

• 该方案确实不符合REST语义规范：POST的原生语义是提交/创建资源，用它承载删除操作会大幅提升接口的理解和维护成本，仅当你方调用链路完全不支持DELETE请求传Body、且其他方案都无法落地时，才作为兜底方案使用。

落地建议 #

如果你的API调用链路（包括接入层、反向代理、日志采集组件）都支持DELETE请求携带请求体，直接选择方案1即可，这是投入产出比最高的方案。如果存在不支持DELETE传Body的组件，优先选择方案4。

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