iOS应用调用Graph API应选择客户端直接调用还是服务端中转调用？

你团队倾向的方案2（后端代理调用Graph API）是更适配当前场景及未来扩展的选择，核心优势和落地注意事项如下：

方案2的核心优势 #

• 客户端令牌管理成本大幅降低：iOS端仅需要维护一套访问自有后端API的令牌即可，不需要处理Graph API不同权限范围、不同资源端点对应的多令牌缓存、刷新、过期处理逻辑，也避免了客户端权限配置出错导致的接口调用失败问题
• 权限管控更安全：所有Graph API的权限配置、调用范围都收拢在后端管控，不需要在iOS客户端暴露Graph的访问凭据，也可以灵活控制返回给客户端的字段范围，避免多余的用户敏感数据（比如个人联系方式、组织架构敏感信息）直接返回给客户端，符合最小权限原则
• 扩展成本更低：后续如果需要扩展邮件、文件等其他Graph API能力，只需要后端新增对应接口、调整Graph的权限配置即可，iOS端不需要做任何SDK接入、令牌逻辑的调整，仅需要对接新增的后端接口就行
• 兼容复杂业务逻辑：如果后续搜索逻辑需要加入自定义过滤规则（比如只允许搜索同部门人员、排除离职人员），直接在后端层处理即可，不需要客户端发版迭代，调整效率更高

方案2落地注意事项 #

• 后端调用Graph API建议使用按需申请的委托权限而非应用权限，确保每次调用都是基于当前登录用户的权限范围执行，避免越权访问其他用户的非公开数据
• 可以在后端层做Graph API的调用结果缓存，针对高频搜索的人员信息做短时间缓存，降低Graph API的调用频次，减少节流触发概率，也能提升iOS端的搜索响应速度
• 如果后续有大量批量查询需求，可以用Graph的$batch接口合并多个请求，进一步提升调用效率

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