复用支持通配符搜索的POST请求通过ID获取资源是否为不良实践？

结论：这属于REST设计中的不良实践，除非有特殊的、无法通过GET解决的场景 #

核心原因：违反HTTP方法的语义约定 #

REST架构的核心之一是利用HTTP方法的标准语义对应资源操作：

• GET：用于安全、幂等地获取资源，自带可缓存、可书签化、调试便捷的特性
• POST：用于提交数据、创建资源或执行非幂等操作，不具备缓存能力，也无法直接通过URL分享或保存

复用POST接口获取特定资源，相当于把“读取资源”这个本该归GET的操作硬塞进POST里，打破了开发者对HTTP方法的普遍认知，会带来一系列实际问题：

具体问题点 #

• 缓存失效：CDN、浏览器、API网关通常只会缓存GET请求，POST请求每次都会直接打到后端服务器，增加不必要的负载，拖慢系统性能
• 无法书签/分享：用户没法把特定资源的请求存成书签，也不能直接复制URL分享给他人，影响使用体验
• 调试与维护成本高：GET请求的参数直接体现在URL里，用浏览器、Postman就能快速测试；POST需要构造请求体，排查问题步骤更繁琐，新开发者接手时还得额外理解这种非标准设计
• 破坏REST统一接口原则：REST强调用标准HTTP方法+资源路径表达操作，这种复用会让接口语义模糊，团队协作时容易产生误解

例外场景（仅万不得已时使用） #

如果存在以下特殊情况，用POST替代GET可能是无奈之举，但必须做好明确文档说明：

• ID过长超出URL限制：部分浏览器或服务器对URL长度有上限（比如常见的2048字符），若资源ID超长无法放入GET参数
• 敏感参数不能暴露在URL中：若获取资源需携带敏感信息，GET的URL会被服务器日志、代理日志记录，存在安全风险（但优先考虑用HTTPS加密URL，或把敏感信息放在HTTP头里，而非直接用POST）

对架构师提议的建议 #

减少接口数量、复用代码的初衷可以理解，但不能以牺牲REST的可维护性和标准性为代价。更合理的做法是：

• 保留GET some/resource/by/{id}的标准接口，严格遵循HTTP语义
• 若想复用搜索逻辑，在后端层面抽象公共查询服务，让GET和POST接口都调用这个服务，而非在接口层面强行复用

总的来说，遵循HTTP方法的标准语义是REST API设计的基础，这种复用POST做GET的操作，除非有特殊场景，否则不应该被采纳。

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