HTTP 请求方法选择与 RESTful 实践（对比 GraphQL、RPC）
HTTP请求方法在实际开发中并非仅使用POST但确实存在简化使用现象。早期因技术限制如浏览器表单仅支持GET/POST和简化思维导致过度使用POST。现代开发推荐RESTful风格GET查询、POST创建、PUT/PATCH更新、DELETE删除以提升语义清晰度和利用HTTP原生优势缓存、幂等性。特殊场景如GraphQL主要用POST属设计选择。不同API风格对比显示RESTful适合标准化CRUDGraphQL适合复杂查询RPC适合高性能通信。行业趋势呈现GraphQL在复杂前端的增长RESTful在企业级的主流地位以及微服务中gRPC的广泛应用。HTTP的请求方式有很多为什么实际开发中大多统一只用post请求这是一个很好的观察但在实际开发中并不是“大多统一只用post请求”而是正确使用不同的HTTP方法。不过你提到的现象确实存在我来分析一下可能的原因和现实情况 为什么会有“只用POST”的现象1.历史遗留问题GET /api/users/delete?id123早期很多项目特别是早期Web应用确实只用GET/POST因为浏览器表单只支持GET/POST一些旧框架/代理服务器对PUT/DELETE支持不好2.简单化思维// “统一POST派”的常见写法 POST /api/users // 创建 POST /api/users/update // 更新 POST /api/users/delete // 删除优点所有操作统一接口风格无状态性考虑简单3.绕过限制绕过某些防火墙对特定方法的过滤简化CORS预检请求POST相对宽松✅现代开发的正确做法RESTful API实际开发中推荐使用语义化的HTTP方法RESTful风格示例GET /api/users # 获取用户列表 GET /api/users/{id} # 获取单个用户 POST /api/users # 创建用户 PUT /api/users/{id} # 更新整个用户 PATCH /api/users/{id} # 部分更新用户 DELETE /api/users/{id} # 删除用户 不同HTTP方法的使用场景方法安全性幂等性典型场景GET✅ 安全✅ 幂等查询数据不修改资源POST❌ 不安全❌ 不幂等创建新资源非幂等操作PUT❌ 不安全✅ 幂等完整更新资源PATCH❌ 不安全❌ 可能不幂等部分更新资源DELETE❌ 不安全✅ 幂等删除资源 只用POST的问题1.语义不清晰// 模糊的接口 POST /api/users // 这是在创建更新还是查询2.失去HTTP原生优势缓存机制GET可被缓存幂等性保证PUT/DELETE的自动重试可观测性监控工具能区分操作类型3.违背REST设计原则// 反模式所有操作都用POST POST /api/getUsers POST /api/createUser POST /api/updateUser POST /api/deleteUser 实际开发建议何时主要用POST非RESTful场景如RPC风格接口复杂操作涉及多个资源的变更文件上传传统表单提交安全性考虑避免敏感参数出现在URL现代最佳实践// 前端请求示例使用正确的HTTP方法 const api { // 查询用GET getUsers: () axios.get(/api/users), // 创建用POST createUser: (data) axios.post(/api/users, data), // 更新用PUT/PATCH updateUser: (id, data) axios.put(/api/users/${id}, data), // 删除用DELETE deleteUser: (id) axios.delete(/api/users/${id}) }; 总结实际上专业开发中不会“统一只用POST”而是80%的项目遵循RESTful或类似规范GET用于读POST用于创建PUT/PATCH用于更新DELETE用于删除特殊场景如GraphQL确实主要用POST但这是设计选择不是随意统一推荐做法根据操作语义选择HTTP方法这样代码更清晰、更可维护也更能利用HTTP协议的优势。使用表格总结对比RESTful、GraphQL、RPCHTTP API 设计风格对比表对比维度RESTfulGraphQLRPC核心理念资源为中心的架构查询语言为中心过程调用为中心请求方法GET, POST, PUT, DELETE, PATCH主要用POST查询/变更主要用POST端点设计资源导向/users,/users/{id}单一端点/graphql动作导向/createUser,/getOrders数据格式通常JSON/XMLGraphQL Schema定义通常JSON/XML/二进制请求结构URL HTTP方法 头信息GraphQL查询语言函数名 参数响应结构预定义的资源结构客户端指定返回字段预定义的返回结构版本管理URL版本/v1/users或Header版本Schema演进字段弃用机制URL版本/v2/createUser缓存机制利用HTTP缓存GET请求需要自定义缓存策略通常无标准缓存超媒体HATEOAS理想情况无无错误处理HTTP状态码 消息体统一的200状态码errors字段自定义错误码/消息 典型使用场景对比场景推荐选择原因简单CRUD操作RESTful天然匹配开发简单复杂数据查询GraphQL避免多次请求按需取字段微服务间通信RPC/gRPC性能高类型安全移动端APIGraphQL减少网络请求节省流量公开APIRESTful标准化易理解工具支持多实时更新GraphQL订阅/RPC实时数据推送需求 技术特性对比特性RESTfulGraphQLRPC类型系统无内置需Swagger等强类型Schema通常有IDL定义文档生成OpenAPI/SwaggerGraphQL Schema自文档需额外工具学习曲线低中高中前端灵活性低固定返回高客户端定制低固定返回后端复杂度低高解析器实现中网络请求数可能多n1问题通常少批量查询视设计而定 实际代码示例对比RESTfulGET /api/v1/users/123 GET /api/v1/users/123/ordersGraphQLgraphqlquery { user(id: 123) { name email orders { id total } } }RPChttpPOST /api/getUser { method: getUser, params: {id: 123}, id: 1 }✅ 选择建议选择RESTful当需要标准化的公共API简单CRUD操作希望利用HTTP缓存选择GraphQL当客户端需求多变需要减少网络请求有复杂数据关系选择RPC当微服务内部通信需要高性能如gRPC操作更像命令而非资源操作 行业趋势现代应用越来越多采用GraphQL特别是移动端和复杂前端应用企业级RESTful仍是主流成熟稳定微服务RPC特别是gRPC在服务间通信占主导混合方案许多公司采用RESTful GraphQL混合架构
)
