JWT鉴权场景下，GET接口传ID获取子管理员信息的合理性及替代方案咨询

当前方案是否合理？ #

当前采用GET domain/api/user/get_by_id/{id}加JWT鉴权的方案是合理的，原因如下：

• GET请求符合HTTP语义中「查询资源」的定义，RESTful风格下，通过URL路径参数指定单个资源ID是查询单条用户信息的常规做法；
• JWT鉴权能有效验证调用者身份，只要在鉴权逻辑中严格校验token中的角色为超级管理员，就能确保只有授权用户可执行该操作；
• URL传ID的方式简单直观，便于调试和日志追踪，只要鉴权逻辑无漏洞，不存在额外的安全风险。

需要注意的细节：务必在JWT校验环节不仅验证token的有效性，还要校验token携带的用户角色是否为超级管理员，避免普通用户通过构造ID进行越权访问。

无需URL直接放ID的替代实现方式 #

如果出于某些场景需求（比如不想让ID出现在URL日志、地址栏），可以采用以下几种方式：

• 请求体传递ID（POST请求）：将目标用户ID放在POST请求的JSON体中（如{"targetUserId": 123}），接口改为POST domain/api/user/get_detail。这种方式避开了URL传参，但要注意POST语义通常对应「创建/修改」，不过在实际业务中，若有明确需求，这种实现也可接受；
• 自定义请求头传递ID：新增自定义请求头（如X-Target-User-ID），将目标用户ID放入该头中，接口仍使用GET方法。这种方式不会将ID暴露在URL里，适合对日志隐私有要求的场景；
• 通过唯一标识替代ID：如果系统中存在其他全局唯一的用户标识（如用户名、邮箱），可以通过查询参数传递该标识，比如GET domain/api/user/get_by_username?username=admin01，本质是用其他唯一标识替代ID，避免直接在URL中暴露用户ID。

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