API 监控可以用哪些 HTTP 方法？

GET、POST、PUT、DELETE、PATCH 和 HEAD。每个监控都可单独配置方法——如 write 类型端点（POST/PUT/PATCH），请求体也可配置为 JSON 字符串或表单数据。

JSON 断言如何工作？

输入 JSON 路径（如 data.status 或 results[0].id）及期望值。监控获取响应后解析为 JSON，提取对应路径并与期望值比较。如果不符，则检测失败，报 "assertion failed" 并显示实际值。

可以发送认证请求头吗？

可以。每个监控都可配置自定义 HTTP 头——Authorization 令牌、API 密钥、content-type 等等。请求头值在数据库中静态加密。Basic Auth 有专用用户名/密码字段，系统会自动签名请求。

如果我的 API 返回 200 并带错误 payload 怎么办？

这很常见：API 返回 HTTP 200，但 body 是 {"status":"error"}。普通可用性监控会误判为健康。使用 JSON 断言 status == "ok" 捕获这种情况——断言失败，监控会报 DOWN，即使 HTTP 状态是 200。

如何应对有速率限制的 API？

将检测间隔设置为符合 API 限额（比如 API 只允许每小时 12 次调用就设为 5 分钟一次）。每次检测只算一次 API 调用，每个区域一次。多区域监控会乘以区域数调用——如 API 限制严格请仅用单区域检测。

API 监控 — HTTP、JSON、Bearer 验证

REST API 需要的不只是 200 OK 检查。请校验方法、请求头、请求体、JSON 路径和精确响应码。

为什么 API 需要专属的监控

API 不只是 /api/ 下的某个页面。它是一个契约。HTTP 方法很重要 —— GET 和 POST 会改变语义。请求头携带认证信息、内容协商、幂等键。请求体是输入。响应码很关键（401、403、422 每个说的是不同的故事）。响应体有其结构——集成方依赖的 JSON 路径。普通的 uptime 检查只用 GET 访问 URL，会遗漏大多数 API 失效的情况：返回 200 的无效 JSON、认证端点接受错误数据、webhook 的 payload 结构出错、端点返回 200 但 body 里是 "status": "error"。

API 监控可以解决这些问题，让你可以控制请求的每个部分及响应验证的每个细节。你可以配置和集成方完全一致的调用——相同的方法、相同的请求头、相同的 body、相同的认证方式——以及什么才叫做成功——精确的响应码、JSON 路径下的具体值、响应时间阈值、大小限制。

请求配置

在 DiagnoSEO Uptime Monitoring 中，每一个 API 监控都可以配置：

HTTP 方法：GET、POST、PUT、PATCH、DELETE、HEAD。选择和你的集成方使用的相同方法。
自定义请求头：以 JSON 对象形式书写，比如 {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}。标准用法用于测试 OAuth、JWT、API 密钥、内容协商。
请求体：任意字符串——JSON、XML、form-encoded、纯文本。在 POST/PUT/PATCH/DELETE 时发送。
Basic 认证：如端点需要保护，填写用户名和密码。
预期响应码：可配置为列表或区间。默认 200-399，但也可以指定单一响应码（如创建端点精确为 201），或允许多个（如 200,202,204）。

检测会跟随最多 5 次重定向，解码 gzip，解析 Content-Type 以识别 JSON。每次检测都会记录实际响应码、响应时间、大小及可能的错误。多次连续故障（可配置，默认2次）会触发事件。

JSON path 断言

仅凭响应码对于很多 API 不够用。健康检查端点可能返回 200，但 body 为 {"status": "degraded", "db": "down"}——虽然是 200，但你绝对需要知道。价格 API 可能返回 200，但 data.price 已降为 null。搜索 API 可能 200 但 results: [] 说明索引异常。

针对这些情况配置 JSON path 断言。设定路径（如 data.status 或 health.checks.db）及期望值（如 healthy、true 或具体数字）。每次检测会解码 JSON 并比较路径下的值。不匹配会导致检测失败，无论 HTTP 状态如何。

路径语法为点号及括号表示法：data.items[0].id 可以用，users.john.email 也一样。断言值作为字符串比较，所以 "true" 可以与布尔 true 匹配，数字也可作为字符串或数字匹配。

认证范式

两种常见认证方式均可直接支持。对 Bearer 令牌（OAuth、JWT、API 密钥），请在 headers 处填写：{"Authorization": "Bearer eyJhbGciOi..."}。令牌放在监控配置里，每次请求都会带上。对于 Basic 认证，使用专用字段填写用户名/密码，然后自动组装成标准请求头。

如果认证需要每次请求签名或刷新令牌，则处理起来难度会高一些。有两种合理模式：(1) 配置一个长效的服务账户 token 专门供监控用，或 (2) 提供一个无需认证的健康检查端点，反映真实受保护端点的状态，并对该端点进行监控。大多数现代 API 都已自带这类端点。

与其他类型监控结合

每个 API 端点的 API 监控验证接口正常。独立的 ping 或端口监控检测主机存活。对同一主机名的 SSL/域名检查可发现证书或注册问题。子监控的 DNS 检查防止记录变更导致指向被篡改。四类监控协同，API 获得全方位保障且重复最小。

配置方式

打开工具，点击“添加监控”，选择“API”类型。粘贴 URL，展开高级选项。选择方法，粘贴请求头 JSON，如需发 body 则填写，若用 basic 认证则配置，输入预期响应码（如 200 或 200,201）。如需可加 JSON 路径断言。设定检测间隔与确认阈值。保存。从下个周期起，监控会严格按集成方方式请求你的 API，验证响应并在秒级发现回归时报警。

常见问题

API 监控可以用哪些 HTTP 方法？
GET、POST、PUT、DELETE、PATCH 和 HEAD。每个监控都可单独配置方法——如 write 类型端点（POST/PUT/PATCH），请求体也可配置为 JSON 字符串或表单数据。
JSON 断言如何工作？
输入 JSON 路径（如 data.status 或 results[0].id）及期望值。监控获取响应后解析为 JSON，提取对应路径并与期望值比较。如果不符，则检测失败，报 "assertion failed" 并显示实际值。
可以发送认证请求头吗？
可以。每个监控都可配置自定义 HTTP 头——Authorization 令牌、API 密钥、content-type 等等。请求头值在数据库中静态加密。Basic Auth 有专用用户名/密码字段，系统会自动签名请求。
如果我的 API 返回 200 并带错误 payload 怎么办？
这很常见：API 返回 HTTP 200，但 body 是 {"status":"error"}。普通可用性监控会误判为健康。使用 JSON 断言 status == "ok" 捕获这种情况——断言失败，监控会报 DOWN，即使 HTTP 状态是 200。
如何应对有速率限制的 API？
将检测间隔设置为符合 API 限额（比如 API 只允许每小时 12 次调用就设为 5 分钟一次）。每次检测只算一次 API 调用，每个区域一次。多区域监控会乘以区域数调用——如 API 限制严格请仅用单区域检测。

API 监控