AWS API网关aws-proxy事件path与resource/resourcePath区别

两个字段本质是「路由规则模板」和「实际请求路径」的区别：

• resource（与requestContext.resourcePath取值完全一致）：存的是你在API Gateway控制台/CloudFormation模板里配置的静态路由匹配规则，是带路径参数占位符、通配符的原始模板。比如你配置了/users/{id}、/{proxy+}这类路由，这个字段就原样返回你配置的模板字符串，作用是标记当前请求命中了哪条API路由规则，不会随请求参数变化。
• path（与requestContext.path取值对应）：存的是调用方发起请求时的真实访问路径，所有路径占位符都会被替换成实际值，没有通配符。要注意两个path的小区别：顶层的path不带stage前缀，requestContext.path会带上API部署的stage前缀（比如示例里的/prod前缀）。

举个实际场景的对应值参考：假设你配置的路由规则是/notes/{noteId}，部署在dev stage，用户实际访问的地址是https://<api-id>.execute-api.<region>.amazonaws.com/dev/notes/9876，对应字段值如下：

{
  "resource": "/notes/{noteId}",
  "path": "/notes/9876",
  "requestContext": {
    "resourcePath": "/notes/{noteId}",
    "path": "/dev/notes/9876"
  },
  "pathParameters": {
    "noteId": "9876"
  }
}

本地调试不用严格对齐线上所有字段的格式，只要保证你的Lambda业务逻辑依赖的字段填对就行，这两个字段按下面规则填不会出问题：

• resource和requestContext.resourcePath：直接抄你CloudFormation中APIEvent配置的Path值就行，比如你模板里写的路由是/api/login就填/api/login，写的是/{proxy+}就填/{proxy+}，不要替换里面的{param}占位符或者+通配符。
• 顶层path：填你要模拟的真实请求路径，不带stage前缀。比如你要测试访问用户ID为123的详情接口，就填/users/123；要测试proxy代理的静态资源路径，就填/static/css/main.css。
• requestContext.path：在你填的顶层path前面拼接stage前缀即可，比如你模拟prod环境就拼/prod，模拟test环境就拼/test。如果你的业务代码不读取这个字段做逻辑判断，随便填个符合格式的字符串也不影响调试。
• 额外注意：如果你的路由带路径参数，记得同步把参数键值对填到pathParameters字段里，键名要和resource里的占位符名完全一致，否则代码里读取路径参数会拿到空值。

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