JMAP与现代邮件应用的架构

设计同步边界

小团队的精力有限。花在协调网络对话上的每一小时，都无法再用于解释导入失败或改善邮件显示。JMAP在客户端本地模型与邮箱服务之间提供更一致的边界。它的价值在于架构清晰，而不是承诺邮件开发从此毫不费力。

基础是2019年发布的 RFC 8620。同年发布的 RFC 8621定义了JMAP邮件模型，包括邮件对象、邮箱、会话和客户端提交发送。它是有明确数据模型的开放标准，而不是需要客户端逆向推测的私有接口。

JMAP通过HTTPS交换JSON。一次请求可包含多个方法调用，后续调用可以引用前面调用的结果。对于收件箱界面，可以将查询及其结果标识对应的数据获取放在一起描述，但必须遵守服务器公布的限制。减少相互依赖的网络往返，在高延迟连接中可能有帮助；实际效果取决于工作负载和实现。

对开发者来说，优势是依赖关系明确：界面需要哪些属性，哪个结果供下一步使用。分页、错误处理和工作量限制依然必需。批量调用用于组织请求，不代表每次打开窗口都应下载整个账户。

状态令牌让客户端询问自已知状态以来发生了哪些变化。/changes返回已创建、已更新和已销毁对象的标识；客户端再获取所需数据并更新本地存储。推送通知提示状态变化，触发同步，但不能代替实际的状态核对。

检查点必须对应已经持久保存的数据。收到响应后、保存之前发生崩溃，也应在设计中处理。如果服务器无法计算所请求的变更历史，会返回cannotCalculateChanges，此时需要更全面的重新同步。长时间离线后的恢复属于正常设计，而不是上线后的补充功能。

JMAP不会替代服务器之间投递所用的SMTP。客户端提交发送与邮件网络中的投递是不同任务。采用JMAP也不会自动消除垃圾邮件、提供端到端隐私或实现离线功能。离线体验仍需本地存储、待执行操作的规则和冲突处理。

支持并不普遍。产品需要发现能力、决定支持哪些服务商，并保留必要的兼容路径。性能取决于服务器、客户端和工作负载。现代IMAP同样具备同步能力，不能只用新旧来比较。

工作室应选择能让恢复过程清晰可理解的契约。为什么邮件应用难做：从工作室视角看五十年的兼容性解释继承而来的约束， JMAP如何让邮件现代化提供用户视角。清晰的服务器通信为更好的应用腾出空间，但团队仍需亲手把它做好。