JMAP（JSON Meta Application Protocol）是一套基于 JSON 和 HTTP 的现代数据访问与同步协议，由 Fastmail 团队推动并提交 IETF 标准化。JMAP Core 于 2019 年发布为 RFC 8620，邮件数据模型则定义于 RFC 8621，并进一步扩展到日历、联系人等场景。

JMAP 目前主要集中在邮件系统的数据访问和同步，其次扩展到日历、联系人等协作数据。它并不是一个“所有邮件系统都在用”的协议，更适合服务端和客户端都可以控制的现代邮件体系。

设计理念

传统 IMAP 主要面向邮件访问，协议交互较为复杂，客户端需要处理 UID、UIDVALIDITY、MODSEQ 等状态，在移动网络环境下进行高效同步也比较繁琐。JMAP 希望通过现代 HTTP API 和结构化数据模型降低客户端实现复杂度。

核心设计包括：

• JSON over HTTP：通过 HTTP API 进行数据访问，通常部署在 HTTPS 之上。
• 批量调用：一次请求可以包含多个方法调用，并允许方法之间通过调用 ID 建立依赖，减少网络往返。
• 显式状态同步：通过 state、changes、queryChanges 等机制进行增量同步。
• 结构化数据模型：邮件、邮箱等资源均使用定义明确的 JSON 对象表示。
• 服务器推送：通过 JMAP 的 pushState 机制配合 EventSource（SSE），客户端可以及时获知数据状态发生变化。

核心机制

1. 方法调用

JMAP 请求主体由 MethodCall[] 构成。每个调用包含方法名、参数和调用 ID，例如：

[
    [
        "Email/get",
        {
            "accountId": "u123",
            "ids": ["M001", "M002"]
        },
        "c1"
    ]
]

服务器返回对应的 MethodResponse[]。一次 HTTP 请求中可以执行多个不同的操作。

2. 状态管理

JMAP 对不同数据类型维护独立的 state。客户端保存自己已经同步到的状态，当需要判断数据是否发生变化时，可以使用 changes 获取自某个状态以来发生的新增、修改和删除。

这种机制使客户端不需要像传统 IMAP 那样通过大量协议交互自行维护复杂的邮箱状态。

3. 数据同步

JMAP Core 提供了多种通用方法：

• get：获取对象；
• set：创建、更新或删除对象；
• changes：获取自指定 state 以来发生的变化；
• query：按照条件查询对象；
• queryChanges：获取查询结果集合的变化。

因此，一个典型的同步流程可以概括为：

首次同步
    ↓
get / query
    ↓
保存 state
    ↓
服务器数据发生变化
    ↓
pushState 通知
    ↓
changes / queryChanges
    ↓
获取增量变化
    ↓
更新本地 state

4. 推送机制

JMAP 可以通过 EventSource（Server-Sent Events）向客户端发送状态变化通知。通知本身通常不携带完整的数据，而是告诉客户端某个数据类型的 state 已经发生变化。

客户端收到通知后，再通过 changes 或相关 API 获取实际变化内容。

这种“通知 + 增量同步”模式可以避免频繁轮询，同时避免推送大量业务数据。

与 IMAP 的对比

应用场景

JMAP 特别适合现代邮件客户端、移动端应用以及需要高效数据同步的服务。Fastmail、Cyrus 等邮件系统已经提供 JMAP 支持，相关生态也在逐步发展。

对于新的邮件系统，如果服务端和客户端均由自己控制，JMAP 相比直接实现 IMAP，通常能够提供更加清晰的 API 模型和同步机制。

局限性

JMAP 最大的问题不是协议设计本身，而是生态兼容性。

IMAP 已经成为邮件客户端和邮件服务器之间事实上的通用协议，大量现有客户端、服务器、网关和第三方工具都支持 IMAP。JMAP 虽然设计更加现代，但生态规模仍无法与 IMAP 相比。

因此，在需要兼容 Thunderbird、Outlook、Apple Mail 等传统邮件客户端时，IMAP 仍然不可替代；如果是自研客户端和自有邮件服务，则 JMAP 的优势会更加明显。

总体而言，JMAP 可以理解为针对现代互联网环境重新设计的一套邮件数据 API。它并不是简单地“用 JSON 重写 IMAP”，而是从数据模型、批量调用、状态同步和 API 设计等方面重新定义客户端与邮件服务器之间的交互方式。