概述
用于 TypeScript 的基于 RxJS 的类型安全 HTTP 客户端和可选的 Next.js/RSocket 适配器
@byeolnaerim/typed-rx-http是一个 HTTP 客户端，通过注入 OpenAPI 风格的路径类型来检查 URL、HTTP 方法、路径/查询参数和请求体的类型，并将结果作为 RxJS Observable 返回。
我在这个库中想要的并不是复杂的 HTTP 抽象，而是直接导入生成的函数并调用，而不是在前端再次编写后端刚刚编写的 URL 和请求/响应 DTO.
Core 基本使用方式
基本流程是准备 OpenAPI 风格的路径类型，必要时创建 HeaderStore，然后通过 createHttpClient<Paths>() 创建客户端并调用 callApi<R>()。自动服务生成器或 WebFlux 后端不是此流程的必需条件。
请求类型由 Paths 决定，响应类型由调用者选择 callApi<R>() 的 R。特定的 ResponseWrapper 也不强制。NDJSON、CSR 缓存、会话认证、Next.js 和 RSocket 功能仅在需要时添加。
起源故事
我在前端使用 Next.js 和 TypeScript，在后端使用 Java 和 WebFlux。由于这个组合，我发现两边重复编写相同内容的情况太多了.
在后端创建实体和请求/响应 DTO 并编写端点。但是在前端调用该端点时，需要重新输入 URL，并且还需要创建与后端 DTO 几乎相同的类型或接口。坦率地说，这与在前端再次编写我在后端编写的内容没有什么不同.
这种重复不仅增加了代码量，而且在一方的字段或 URL 发生变化时，另一方被遗漏的可能性也增加了。因此，我迫切感受到需要将后端的 REST API 规范可预测地生成到前端 HTTP 客户端代码中.
在这个过程中，我在实际项目 nplauction.com 中为后端reactive-mongo-dsl和webflux-fe-dev-assistant的原型，首先在前端应用了 typed-rx-http 的原型。typed-rx-http 并不是从一开始就作为一个独立的想法开始的，而是在创建 webflux-fe-dev-assistant 时，顺便为前端需要的部分一起创建的库.
Swagger 自动生成项目中的使用方式
在使用Swagger服务自动生成的项目中， createHttpClient我并不是每次都编写 URL。项目中 commonService.ts创建一个项目拥有的公共HTTP适配器，只需导入OpenAPI生成的服务函数即可。commonService.ts不是库生成的文件名，而是项目自定义的文件名，可以在开始/HTTP客户端文档中查看完整代码。
const response = await firstValueFrom(
workplacesSearch({ params: { keyword: "kim" } }),
);上述代码中没有 URL 字符串或手动编写的响应接口。URL、HTTP 方法、参数类型和响应类型包含在生成的服务中。一次响应是通过 firstValueFrom接收的，而像工作进度这样的多个值的请求可以通过subscribe接收。
在哪里最合适呢
如果后端和前端是分开的，并且后端可以提供有效的swagger.json，则可以减少 TypeScript 前端的重复工作。如果使用 Java WebFlux 功能端点，可以结合 webflux-fe-dev-assistant 从文档生成到服务生成的过程。
typed-rx-http Core不依赖于WebFlux。与后端实现无关，兼容OpenAPI规范的TypeScript paths 如果有类型，可以减少每次手动编写字符串URL和请求类型的工作。RSocket客户端可以直接在/rsocket入口点使用，只有在需要路由/请求/响应服务自动生成的项目中，才能额外使用AsyncAPI生成器。
swagger.json 或asyncapi-rsocket.json的结构.