Skip to main content
World Monitor 中的所有 JSON API 端点必须使用 sebuf。不要为新的数据 API 创建独立的 api/*.jsapi/*.ts 文件——这一旧模式已被弃用并正在被移除。 本指南将介绍如何为现有服务添加新的 RPC,以及如何添加一个全新的服务。
强制执行: npm run lint:api-contract 会在 CI 中运行(参见 .github/workflows/lint-code.yml)。它会遍历 api/ 下的每个文件,将每个 sebuf 网关(api/<domain>/v<N>/[rpc].ts)与 src/generated/server/worldmonitor/ 下生成的服务配对,并拒绝任何既不是网关也未在 api/api-route-exceptions.json 中列出的文件。该清单是那些确实无法使用 proto 定义的端点(OAuth 回调、二进制响应、上游代理、运维管道)的唯一逃生通道,且每个条目都通过 .github/CODEOWNERS 固定由 @SebastienMelki 负责。新增条目预计会受到审核者的质疑。 生成新鲜度: 修改任何 .proto 文件后,在推送前请运行 make generatesrc/generated/ 中生成的 TypeScript 代码已签入仓库,必须保持同步;如果发生漂移,.github/workflows/proto-check.yml 会导致 PR 失败。

前置条件

你需要安装 Go 1.21+Node.js 18+。其他所有依赖会自动安装:
这会安装:
  • buf —— proto 代码检查、依赖管理和代码生成编排器
  • protoc-gen-ts-client —— 生成 TypeScript 客户端类(来自 sebuf
  • protoc-gen-ts-server —— 生成 TypeScript 服务端处理程序接口(来自 sebuf)
  • protoc-gen-openapiv3 —— 生成 OpenAPI v3 规范(来自 sebuf)
  • npm 依赖 —— 所有 Node.js 包
在仓库根目录运行代码生成:
这会为每个服务生成三个输出:
  • src/generated/client/{domain}/v1/service_client.ts —— 供前端使用的类型化 fetch 客户端
  • src/generated/server/{domain}/v1/service_server.ts —— 供后端使用的处理程序接口 + 路由工厂
  • docs/api/{Domain}Service.openapi.yaml + .json —— OpenAPI v3 文档

为现有服务添加 RPC

示例:将 GetEarthquakeDetails 添加到 SeismologyService

1. 定义请求/响应消息

创建 proto/worldmonitor/seismology/v1/get_earthquake_details.proto

2. 将 RPC 添加到服务定义

编辑 proto/worldmonitor/seismology/v1/service.proto

3. 代码检查并生成

此时,npx tsc --noEmit失败,因为处理程序尚未实现新方法。这是有意为之的——编译器会强制执行契约。

4. 实现处理程序

创建 server/worldmonitor/seismology/v1/get-earthquake-details.ts

5. 将其接入处理程序再导出

编辑 server/worldmonitor/seismology/v1/handler.ts

6. 验证

路由已通过 api/seismology/v1/[rpc].ts 中的领域网关生效。createSeismologyServiceRoutes() 会自动识别新的 RPC——无需编辑路由表或 vite.config.ts

7. 检查生成的文档

打开 docs/api/SeismologyService.openapi.yaml——新端点应当出现,并包含来自你的 proto 注解的所有验证约束。

添加新服务

示例:添加一个假想的 WeatherService。(本仓库中不存在 weather 域——下面的示例纯粹是说明性的;复制粘贴本节的任何路径都会命中 404。)

1. 创建 proto 目录

2. 定义实体消息

创建 proto/worldmonitor/weather/v1/weather_station.proto

3. 定义请求/响应消息

创建 proto/worldmonitor/weather/v1/list_weather_stations.proto

4. 定义服务

创建 proto/worldmonitor/weather/v1/service.proto

5. 生成

6. 实现处理程序

创建处理程序目录和文件:
server/worldmonitor/weather/v1/list-weather-stations.ts
server/worldmonitor/weather/v1/handler.ts

7. 添加每领域边缘网关

创建 api/weather/v1/[rpc].ts 作为此服务的薄 Edge 入口点:
不存在仓库范围的 catch-all 网关文件或共享路由数组需要编辑。每个服务拥有其 api/<domain>/v1/[rpc].ts 网关,生成的 create<Service>Routes(...) 函数为该领域强制 RPC 路径名和 HTTP 注解。

8. 在 Vite 开发服务器中注册

编辑 vite.config.ts——在 sebufApiPlugin() 函数内部添加懒加载导入和路由挂载。遵循现有模式(搜索任何其他服务以查看具体位置)。

9. 创建前端服务包装器

创建 src/services/weather.ts

10. 验证

MCP 暴露决策

每个新的公开 OpenAPI 操作在评审前都需要一个明确的 MCP 决策。MCP 是一个精选的 agent 接口,而非 REST 的 1:1 镜像:暴露安全、可预测且作为工具有用的操作;当操作会变更状态、消耗每次调用的 LLM 或上游预算,或需要手动缓存键审查时,保留为 REST 专属并记录在案。 对每个新增或变更的 RPC 使用以下清单:
  • 决定此操作是否应暴露给 MCP。
  • 若是,确定归属的 MCP 工具,并将确切的 METHOD /api/... 条目添加到该工具的 _apiPaths
  • 若由缓存支持,确认工具具有正确的 _cacheKeys / _coverageKeys、新鲜度元数据和 seed-meta:<key> 健康覆盖。
  • 若否,在 tests/mcp-api-parity.test.mjs 中添加或更新排除项,附带匹配的类别前缀和具体原因。
  • 若为 fetch-on-miss,包含一个强制的辅助信号(high-cardinality-inputpaid-upstreamllm-cost),并说明使当前开放 MCP 暴露不安全的上游成本、基数和分层策略。
  • 若为 mutatingllm-passthrough,在提出 MCP 封装前记录独立的威胁/成本模型。
  • 运行 ./node_modules/.bin/tsx --test tests/mcp-api-parity.test.mjs 并在 PR 中包含结果。
covered 操作在工具的 _apiPaths 条目中声明。对于 REST 专属操作,对等测试接受以下排除类别: MCP 参考文档在 MCP 概览 中渲染当前的 _apiPaths 覆盖表。对等测试是当前已覆盖/已排除拆分的权威来源,因此不要依赖 PR 描述中的过时计数。

Proto 约定

这些约定在整个代码库中被强制执行。请遵循它们以保持一致性。

文件命名

  • 每个消息类型一个文件:earthquake.protoweather_station.proto
  • 每个 RPC 对一个文件:list_earthquakes.protoget_earthquake_details.proto
  • 服务定义:service.proto
  • 文件名和字段名使用 snake_case

时间字段

始终使用 int64 配合 Unix 纪元毫秒。切勿使用 google.protobuf.Timestamp 始终添加 INT64_ENCODING_NUMBER 注解,以便 TypeScript 得到 number 而非 string

验证注解

导入 buf/validate/validate.proto 并在 proto 层面为字段添加注解。这些约束会自动流入生成的 OpenAPI 规范。 常见模式:

共享核心类型

请复用这些类型,而不要重新定义:

注释

buf lint 强制要求所有消息、字段、服务、RPC 和枚举值都必须有注释。每个 proto 元素都必须有 // 注释。这不是可选项——没有注释,buf lint 会失败。

路由路径

  • 服务基础路径:/api/{domain}/v1
  • RPC 路径:使用 kebab-case 的 /{verb}-{noun}(例如 /list-earthquakes/get-vessel-snapshot

处理程序类型定义

始终使用索引访问类型,针对生成的接口为处理程序函数定义类型:
这确保编译器能捕获你的实现与 proto 契约之间的任何不匹配。

客户端构造

创建客户端时始终传入 { fetch: (...args) => globalThis.fetch(...args) }
空字符串作为基础 URL 之所以可行,是因为 Vite 开发服务器和 Vercel 都在同一源上提供 API。围绕 globalThis.fetch 的箭头函数包装器对于 Tauri 兼容性以及运行时 fetch 拦截器是必需的——fetch.bind(globalThis)禁止使用,因为它在模块初始化时冻结了对全局 fetch 的引用,这会绕过后续安装在 globalThis.fetch 上的任何拦截器(认证头、请求日志、重试垫片)。箭头函数包装器会在每次调用时解析 globalThis.fetch

生成的文档

每次运行 make generate 时,都会为每个服务生成 OpenAPI v3 规范:
  • docs/api/{Domain}Service.openapi.yaml —— 人类可读的 YAML
  • docs/api/{Domain}Service.openapi.json —— 机器可读的 JSON
这些规范包括:
  • 所有端点及其请求/响应模式
  • 来自 buf.validate 注解的验证约束(最小/最大值、必填字段、范围)
  • 来自 proto 注释的字段描述
  • 错误响应模式(400 验证错误、500 服务器错误)
你无需手动编写或维护 OpenAPI 规范。它们是生成产物。如果需要更改 API 文档,请更改 proto 并重新生成。