如何获取或生成REST API对应的TypeScript类型

REST 生态完全具备和 GraphQL 生态同等能力的自动类型生成方案，不需要靠手写维护接口类型，结合你既要发 REST 请求、又要消费 Webhook 的场景，具体方案分两类：

• 第一类是基于接口规范生成的方案，稳定性最高，和 GraphQL 代码生成的逻辑完全对齐
  如果服务端提供 OpenAPI（原 Swagger）规范文件（JSON/YAML 格式均可），直接用对应的类型生成工具即可：跑单条命令就能把所有 REST 接口的请求参数、响应体、错误结构的 TS 类型全部导出，只要服务端把 Webhook 的事件结构定义在 OpenAPI 的 webhook 块中，这部分推送 payload 的类型也能同步生成。
  其中openapi-typescript是这类工具里比较常用的，生成的是纯类型文件，没有额外运行时依赖，不管你用原生 fetch、axios 还是其他请求库都可以直接复用类型；如果不想自己封装请求层，也可以选用支持生成带类型请求客户端的工具，直接输出封装好的请求方法，调用时自动带参数、返回值的类型提示。
  如果服务端针对 Webhook 这类异步场景单独提供了 AsyncAPI 规范文档，也有配套的 TS 类型生成工具，可以直接导出所有 Webhook 事件对应的 payload 类型，消费推送时直接复用即可。
• 第二类是无正式接口规范时的兜底方案
  如果服务端没有提供上述标准规范文件，可以用基于实际请求/推送数据生成类型的工具：你可以在本地调试时把接口返回的 JSON、收到的 Webhook payload 样本收集好，工具会自动根据 JSON 结构推导生成对应的 TS 类型；也可以用代理拦截类的工具，你正常跑一遍业务流程覆盖所有 REST 接口、触发一遍所有 Webhook 事件，工具会自动收集所有交互的数据结构，输出统一的类型文件。
  另外还有和请求库深度集成的自动推导方案：第一次发起请求拿到响应后，工具会自动根据返回结构推导类型缓存到本地，后续调用同个接口时就能直接获得类型提示，这类方案适合接口变动频率低的场景，注意要和服务端确认字段的必传/可选规则，避免推导出来的类型和实际稳定返回的结构有偏差。

实操建议：不管用哪种方案生成类型，Webhook 消费逻辑最好加一层轻量运行时校验，不要完全依赖编译时的 TS 类型。TS 类型只在编译阶段生效，万一服务端改了推送字段没同步通知，运行时没有校验很容易触发线上问题，可以把生成的类型和运行时校验库结合使用，不需要重复写结构定义。

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