ts-rest框架中可选查询参数的设计哲学与实践

概述

在REST API开发中，查询参数的处理是一个常见但容易被忽视的细节。ts-rest作为一个类型安全的API契约框架，对查询参数的处理有着独特的设计理念。本文将深入探讨ts-rest中可选查询参数的设计原理和最佳实践。

查询参数的可选性层级

ts-rest框架将查询参数的可选性分为两个层级：

1. 整个查询对象的可选性：通过.optional()方法标记整个查询对象是否可选
2. 单个参数的可选性：通过.optional()方法标记单个参数是否可选

这种分层设计反映了REST API的实际工作方式：即使没有任何查询参数，请求中仍然存在一个空的查询对象。

设计原理

ts-rest团队在设计查询参数可选性时遵循了几个核心原则：

1. 语义一致性：HTTP请求总是包含查询部分，即使为空
2. 类型安全：确保类型系统能准确反映API的契约
3. 显式优于隐式：避免"魔法"行为，保持代码清晰可读

最佳实践

基于这些原则，我们推荐以下实践方式：

// 推荐做法：将单个参数标记为可选
export const contract = c.router({
  getPosts: {
    method: "GET",
    path: `/posts`,
    query: object({ 
      foo: string().optional()  // 单个参数可选
    }),
    responses: {
      200: PostSchema.nullable(),
    },
  },
});

// 客户端调用
const { body, status } = await client.getPosts({ query: {} });

这种方式明确表达了：

• 查询对象总是存在
• 具体参数foo是可选的

为什么不支持完全省略查询对象

ts-rest选择不支持完全省略查询对象的语法（如直接调用client.getPosts()），主要基于以下考虑：

1. HTTP协议本质：即使没有查询参数，URL中的问号部分仍然存在
2. 类型系统完整性：保持类型系统与运行时行为一致
3. 代码可维护性：显式的空对象比隐式省略更易于理解和维护

结论

ts-rest框架对查询参数的处理体现了类型安全与语义准确性的平衡。通过理解其设计哲学，开发者可以编写出更健壮、更易维护的API代码。记住：在ts-rest中，查询对象本身的存在是必须的，而具体的参数才是真正可选的。