RESTful服务器是否仅应将POST用于数据创建？查询场景该如何选择？

你说得太对了，用GET做查询完全贴合RESTful的设计理念，而避免用POST来处理基础查询，核心原因都围绕HTTP方法的语义约定和实际开发中的便利性展开：

1. 别打破HTTP方法的「通用默契」 #

HTTP方法从设计之初就给每个方法赋予了明确的语义，这是所有开发者和工具都默认遵守的规则：

• GET：就是用来获取资源的，它是「幂等且安全」的——多次调用不会改变服务器状态，也不会产生任何副作用（比如写入数据库）。
• POST：则是用来创建新资源或者执行非幂等的操作（比如提交表单创建用户，多次调用可能会生成多个重复用户）。

如果用POST来做查询，相当于打破了这个默契：其他开发者看到POST请求，第一反应会觉得这是个会修改数据的操作，得特意去看请求体才知道是查询，平白增加了理解成本；甚至一些API工具会默认把POST请求标记为「危险操作」，给调试带来麻烦。

2. 浪费GET的原生优势 #

GET请求自带很多对查询场景极其友好的特性，这些都是POST没有的：

• 自动缓存：浏览器、CDN、代理服务器都会自动缓存GET请求的结果，能大幅降低服务器压力，提升查询性能。而POST请求默认不会被缓存，要实现缓存得手动配置一堆规则，麻烦得很。
• 可分享/书签化：GET的过滤参数都在URL里，用户可以把这个查询链接存成书签，或者直接分享给同事，对方打开就能看到完全一样的过滤结果。POST的参数藏在请求体里，根本没法直接分享。
• 调试更直观：不管是在浏览器地址栏敲URL，还是用调试工具测试，GET的参数一目了然；POST的参数得点开请求体才能看，调试效率差很多。

3. 幂等性与安全性的坑 #

GET是「幂等」的——同一个GET请求调用多少次，结果都是一样的，也不会改服务器数据。但POST是非幂等的，哪怕你用它做查询不会改数据，一些工具或框架还是会把它当成「非安全操作」：比如浏览器会弹出「确认重复提交」的提示，或者API网关会对POST请求做额外的防重校验，反而给你添不必要的麻烦。

4. 保持REST资源模型的一致性 #

REST的核心是「资源」，每个资源对应一个清晰的URL。比如GET /users?department=engineering一看就懂：获取工程部的用户集合。但如果用POST /users来做这个查询，就混淆了「创建用户」和「查询用户」的边界，让API变得混乱，后续维护起来会非常头疼。

特殊情况：什么时候可以用POST做查询？ #

当然也不是绝对不能用POST做查询，比如遇到这两种场景时可以妥协：

• 过滤条件特别复杂，参数长度超过了URL的限制（不同服务器的限制不一样，一般是2KB-8KB）；
• 查询参数包含敏感信息（比如用户的隐私数据），不适合放在URL里（因为URL会被存在日志、浏览器历史里）。

但这些都是特殊情况，基础查询一定要优先用GET，既符合规范，又能让你的API更直观、更好用。

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