某技术社区近日热议一个关于API设计的帖子，内容是一位工程师的同事将所有接口统一设定为POST请求，理由是认为HTTPS环境下POST更为安全，这与RESTful API提倡的GET、PUT、DELETE等多种动词使用方式形成冲突。该帖引发了开发者们的各种回应，其中不乏支持“全部使用POST”的声音，他们的原因包括“挺好的，沟通少”、“早点干完早点回家”、“工作而已，优雅不能当饭吃”等。
然而，这种“一把梭”式的开发模式实则埋下隐患。HTTP动词（Method）作为协议头中的控制逻辑部分，其存在并非偶然，而是承载着重要的语义和功能。编程世界分为业务逻辑和控制逻辑，HTTP动词正属于后者，它们通过明确的规范赋予了API不同的行为和特性。
根据RFC7231等规范，不同的HTTP动词对应不同的操作。例如，GET用于查询（幂等）、PUT用于完整更新（幂等）、DELETE用于删除（幂等）、POST用于新增（非幂等），而PATCH则用于局部更新（非幂等）。幂等性是API设计中的关键特性，它意味着多次执行相同操作的结果与执行一次相同操作的结果完全一致，没有副作用。这对于网络请求中可能出现的超时重试情况至关重要。如果所有API都采用非幂等的POST，一旦请求超时，客户端将无法判断服务器是否已处理，盲目重试可能导致灾难性后果，如重复转账。
除了幂等性，HTTP动词的区分还在以下控制逻辑方面发挥作用：
缓存：GET请求易于通过CDN或网关进行缓存，提升性能。 流控：可基于动词实现更细粒度的请求频率限制，区分读写操作的流控策略。 路由：实现读写分离，将不同类型的请求路由至专门的服务集群。 权限：提供更精细的权限控制和审计能力。 监控：区分不同方法的API性能，进行有针对性的分析。 压测：明确的动词有助于组织更有效的压力测试。
即使对于业务不复杂的系统，“读写分离”也至少需要GET（读）和POST（写）两种动词来支撑。在复杂的RESTful查询场景中，如排序、过滤、搜索和分页，GET请求结合查询参数依然是主流。尽管理论上GET可以包含请求体，但考虑到许多库和中间件的兼容性问题，对于复杂查询，如ElasticSearch的DSL，即便优先推荐GET，在客观条件不支持时才退而求其次使用POST。ElasticSearch官方文档也明确指出，倾向于GET来描述“检索信息”的动作，仅在GET带请求体不被普遍支持时才接受POST请求。
对于“POST更安全”的误解，需要澄清的是，无论GET还是POST，只要使用HTTPS协议，传输过程都是加密的。认为GET请求参数暴露在URL中就不安全，而POST则不然，这是一种片面理解。重要的敏感信息应加密处理，并通过URL签名等方式防止篡改。在CSRF等攻击场景中，POST请求反而更容易成为攻击目标。API的安全性是一个系统工程，与HTTP动词本身并无绝对关系。
“全用POST能节省时间、减少沟通”的论调同样站不住脚。为API赋予不同动词几乎不额外耗时，且符合良好编程风格。遵循API规范能显著降低新成员的学习成本和团队间的沟通成本，因为规范本身就是协作的基础。长期来看，不规范的“一把梭”会增加沟通成本，并在后期处理控制逻辑时带来巨大的技术债务，反而延长开发周期。
真正的“早点回家”并非一味追求短期的快速完成，而是通过良好的代码组织、设计和高质量的文档与注释，提升代码的可扩展性和可维护性，减少未来不必要的返工和打扰。作为一个职业程序员，应尊重并热爱自己的职业，遵循行业规范，不断提升专业素养，而非仅仅将工作视为谋生的手段。“你的工作给你权力，而只有你的行为才会给你尊重。”这才是打造有价值职业生涯的根本之道。