REST API参数获取：客户端传参与服务端内部拉取的边界如何划分？

1. 数据一致性与权威性要求 #

如果firstName、lastName属于需要强一致的核心业务字段，比如涉及实名认证、支付校验、法律文书生成等场景，无论客户端是否持有数据，都应该由服务端主动从官方数据源拉取。可以完全避免客户端传递缓存的过期数据、篡改数据导致的业务故障。

2. 链路成本与架构负担 #

可以从两个方向核算成本后选择：

• 若你的API QPS较低，调用内部用户信息接口的额外耗时在可接受范围内，且下游接口无性能压力，优先选择服务端拉取。可以降低客户端的传参复杂度，避免多端适配时的参数错漏问题。
• 若你的API属于高QPS核心接口，且用户信息查询接口本身存在性能瓶颈，或是调用链路会产生额外的计费成本，优先让已持有数据的客户端直接传参，避免流量放大压垮下游依赖。

3. 业务场景灵活性要求 #

如果业务存在自定义字段的需求，比如允许用户在当前业务线设置专属展示名替代官方姓名，必须保留客户端传参的入口。如果没有类似需求，统一服务端拉取可以减少参数校验的逻辑复杂度。

4. 安全合规要求 #

如果firstName、lastName属于敏感个人信息，客户端公网传输需要额外做加密处理，或是部分端（比如第三方合作方、IoT设备）没有权限获取这类敏感数据，由服务端在内网环境拉取更符合数据合规要求，降低敏感信息泄露风险。

通用折中方案 #

如果无法覆盖所有调用方的场景，可以设计兼容逻辑：

客户端可以选择是否上传firstName、lastName参数，服务端优先使用客户端传递的值；如果参数为空，服务端自动调用用户接口拉取对应数据。
该方案几乎没有额外开发成本，同时适配两类调用方的需求。

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