RESTful设计：二十一点服务应拆分GET接口还是合并为单动作接口？

首先纠正现有设计的核心问题 #

你当前设计的4个GET端点本身不符合REST规范：

• GET请求的语义是安全、幂等的，即多次调用不会修改服务端资源状态，也不会产生副作用
• 你提到的hit/stand/double down/surrender都是会修改牌局状态的操作，绝对不能用GET实现，否则会出现浏览器预请求、缓存导致的非预期状态修改问题

两种可行方案的对比 #

首先REST规范的核心是以资源为中心，你首先要把牌局抽象为独立资源，基础URI建议统一为/games/{gameId}，所有操作都围绕这个资源展开。

方案1：拆分为独立端点（推荐优先选择） #

将四个动作作为牌局资源的子操作，全部用POST请求，端点设计为：

• POST /games/{gameId}/hit
• POST /games/{gameId}/stand
• POST /games/{gameId}/double-down
• POST /games/{gameId}/surrender

优势：

• 语义完全透明，看URI就能知道操作类型，调试、排查问题不需要解析请求体
• 每个接口的参数、校验逻辑完全独立，代码逻辑清晰，不容易出耦合问题
• 接口文档直观，前端对接成本低

劣势：

• 端点数量随动作增加而增加，如果后续要加split/insurance等二十一点扩展操作，需要新增对应端点

方案2：合并为单个操作接口 #

可以设计为POST /games/{gameId}/actions，通过DTO传递动作参数，请求体示例：

{
  "action": "double_down",
  "bet_amount": 100
}

优势：

• 接口数量固定，新增动作不需要新增路由，扩展性好
• 所有动作的公共逻辑（比如牌局状态校验、权限校验）可以统一处理

劣势：

• 语义不直观，需要解析请求体才能确定操作类型，日志排查、调试成本更高
• 参数校验逻辑需要根据动作类型分支处理，代码复杂度更高

最终建议 #

两种方案都符合REST规范，实用性选择可以参考你的业务需求：

• 如果你的业务仅需要这四个基础动作，优先选拆分方案，开发、维护、对接成本都更低
• 如果后续需要扩展大量二十一点的特殊规则动作，选合并方案更适合长期维护

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