如何通过rewrite规则实现Restful_API参数重构-Nginx-PHP中文网

核心是让前端Restful路径被后端正确识别：可原样透传（推荐，用proxy_pass http://backend/;）或转查询参数（如rewrite ^/api/...$ /user?id=$1? break;），关键在正则location捕获、proxy_pass末尾斜杠及避免滥用rewrite。

如何通过rewrite规则实现restful_api参数重构

核心是让前端调用的 Restful 风格路径（如 /api/users/123）被后端服务正确识别——要么原样透传供其解析路径参数，要么转成查询参数（如 /user?id=123）。关键不在 rewrite 本身多复杂，而在匹配方式、捕获逻辑和与 proxy_pass 的配合是否合理。

用正则 location 捕获路径参数

只有带 ~ 或 ~* 的正则 location 才能提取变量。前缀匹配（如 location /api/）做不到。

写法示例：location ~ ^/api/v1/users/(\d+)$ —— (\d+) 捕获 ID，后续用 $1 引用
命名捕获更清晰（需 Nginx ≥ 1.11.0）：location ~ ^/api/v1/users/(?\d+)$，引用为 $id
避免写成 location ~ /users/(\d+) 这类宽泛匹配，容易误伤其他路径

rewrite 转成查询参数（适合老后端）

当后端只认 ?id=123 这种形式时，rewrite 是必要手段：

规则示例：rewrite ^/api/v1/users/(\d+)$ /user?id=$1? break;
末尾 ? 很关键：它清空原始 query string，防止变成 /user?id=123&origin=q
用 break 终止当前 location 内 rewrite，直接走 proxy_pass；用 last 会重新匹配 location，易引发循环

保持路径结构，仅剥离前缀透传（推荐做法）

现代框架（Spring Boot、Express 等）原生支持路径参数，无需改写。此时 rewrite 反而是冗余的：

简洁写法：location /api/ { proxy_pass http://backend/; }
注意 proxy_pass 末尾的 /：它会把请求 /api/v1/users/123 转发为 http://backend/v1/users/123
若漏掉斜杠（proxy_pass http://backend;），则完整路径 /api/v1/users/123 会被转发过去，后端可能收不到预期路径