逻辑接口和配置接口你们会分开还是合并那?

比如有一个业务逻辑: 新用户弹窗, 弹窗要能配置开关(关所有都不弹, 开则需要判断是否是新老用户)

• 方法 1

1. 配置接口返回开关
2. 用户接口返回新老用户判断
3. 客户端取两个接口判断

• 方法 2

1. 服务端合并接口返回配置和是否新老用

过了一个月, 需要增加一个老用户判断(同样需要配置)

• 方法 1

1. 配置接口返回开关
2. 用户接口返回新老用户判断
3. 客户端取两个接口判断

• 方法 2

1. 服务端合并接口返回配置和是否新老用

过了一个月, 需要增加一个福利弹窗开关 xxxx 类似, 有这样的一个系统, 你更青睐哪种设计或者有更好的方案?

逻辑判断放服务端接口，前端无需判断用户权限及逻辑，可以随时调整。比如首页要展示几个弹窗，搞一个数组里面，在前端只需要判断数组长度，有则弹。这样 api 端控制的好处是，随时可以调整规则，无需更新 APP/小程序。

根据两者是否是同一领域来决定。 弹窗和用户本身不是同一领域的，不同领域的服务可能不在同一个系统上，比如我司就区分了配置中心和用户中心，各个业务还有自己的业务字段，这里如果合起来依赖关系会很复杂，所以我比较倾向于分开来。 如果现在增加了一个需求：比如老用户可以绑定邮箱和手机号，而新用户只能绑定手机号，这个可以认为属于同一个领域，所以就服务端合并下发配置。

@seanlin5 @renmu 上面是举例, 现在情况有一个类似这样的逻辑. 部分菜单功能是 A 服务返回, 判断是新用户服务在 B 上, A 服务应该请求 B 服务吗? 类似的点比较多, 首页五个地方都要新用户判断, 是在服务端请求 5 次, 还是客户端初始化请求一次判断, 当前 session 使用

@javalaw2010 现在情况和你说的领域有点像, 现在是在好几个服务商