同一微服务下多资源RESTful URL设计合理性咨询

• 逐点对照你列的设计做校验：
  • /groups/ 作为路径本身没有硬伤，但REST语义下这个路径通常绑定GET（获取群组列表）、POST（创建新群组）方法，单独留空路径不绑定方法的话容易出现路由匹配歧义
  • /groups/add/ 不符合REST设计惯例：不需要把add这类操作动作写进路径段，创建群组直接把POST方法绑定在/groups根路径即可，末尾带的多余斜杠在API Gateway路由配置中很容易触发路径匹配不生效的问题
  • groups/:groupId/remove 存在两个硬错误：一是开头缺失斜杠，API Gateway默认的路由匹配规则会直接把这个路径判定为非法返回404；二是把remove这类操作动作写进路径，删除群组直接把DELETE方法绑定在/groups/:groupId路径即可，不需要额外加remove路径段
  • /group/:groupId/addUser/:userId 存在风格不统一、语义冗余的问题：前面所有群组路径全用groups复数形式，这里突然变成group单数，会增加前端和客户端的记忆成本；同时addUser是冗余的动作描述，用户和群组的关联关系本身就是群组下的子资源，不需要单独写addUser路径

• 结论是完全符合通用设计规范，和当前的AWS无服务器架构适配性极强
• 不存在“一个微服务只能对应一个路由基础路径”的硬性规则：不管是传统单体微服务还是Lambda托管的无服务逻辑，路由路径设计的核心依据是资源的层级关系，和数据存在哪张表、由哪个代码块托管没有必然绑定关系
• 你当前的场景下，用户和群组数据共存在同一张Dynamo表、由同一个Lambda函数统一处理逻辑，完全可以为两类资源分别设置独立的路径基础，反而比强行把两类资源揉在同一个路径前缀下的逻辑更清晰
• 实际在AWS API Gateway配置时，同一个Lambda函数本身就支持挂载多路由规则，通过请求路径前缀分流到对应的处理逻辑，不存在任何配置上的阻碍

• 保留你已经定型的用户类端点设计：
  • /user/invites
  • /user/:userId/save
  • /user/:userId/activate
• 修正后的群组类端点（在不强行改你已经习惯的动作式路径写法的前提下，和现有设计风格对齐）：
  • /groups 承接群组列表查询、新建群组的请求
  • /groups/:groupId/remove 补上开头的斜杠，承接删除群组的请求
  • /groups/:groupId/addUser/:userId 把单数的group改成groups保持单复数统一，承接添加用户到群组的请求

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