正常情况下，开发人员会根据实际需求，提供API服务，将需要的数据提供给使用方。这样的好处是，可以更加细致的控制数据的返回，以及更灵活的数据权限的控制。
在某些场景下，更关注的是数据的可获得性。实际的需求可能多种多样，如果针对每个需求，都提供单独的API，那么API的数据会显著增加，开发和维护成本也会增加。一种方式是通过良好的API设计，提供更多的筛选条件来合并相似数据获取的需求。另一种方式，是将筛选和查询的能力提供给使用方，让使用方自行决定需要的数据，比如GraphQL和OData，或者使用其他的工具，如data-api-builder，直接生成API服务，来提供数据。
这类方法，能够快速的提供数据获取的能力，但在面对复杂的查询和更细致的数据控制时，可能无法满足需求。
我们将介绍和对比一下这几种方式，以及它们的优缺点。
下面是对 GraphQL、OData 和 Data API Builder 三种技术/工具的介绍和对比：
概述
GraphQL 是由 Facebook 提出的 API 查询语言，它允许客户端精确指定所需数据，避免了传统 REST API 中可能出现的数据过多或不足的问题。GraphQL 采用强类型模式，通过单一端点支持嵌套查询、聚合以及订阅（实时更新）等功能。
优点
适用场景
概述
OData（Open Data Protocol）是一个开放标准，用于构建和消费 RESTful API。它通过标准化的查询参数（如 $filter、$select、$expand 等）为客户端提供一致的数据访问方式，特别适合数据驱动型的企业应用。
优点
适用场景
概述
Data API Builder（通常由 Microsoft 提供）是一款低代码工具，它能自动为关系型或 NoSQL 数据库生成 RESTful API 接口。它内置对 OData 查询参数的支持，同时集成了安全（例如基于角色的访问控制）和自定义扩展功能。
优点
适用场景
| 特性 | GraphQL | OData | Data API Builder |
|---|---|---|---|
| 查询方式 | 灵活的查询语言，支持嵌套、聚合、订阅 | 基于 REST，利用标准 URL 查询参数 | 自动生成 RESTful 接口，可支持 OData 查询 |
| 灵活性 | 客户端按需定制查询，灵活度高 | 标准化但相对固定，适合数据驱动场景 | 快速、自动化，适合快速搭建简单 API |
| 开发门槛 | 需要学习 GraphQL 规范及相关工具 | 遵循 REST 标准，门槛较低 | 低代码工具，配置简单易用 |
| 生态与集成 | 独立于平台，可与各种前端和后端集成 | 适合 Microsoft 生态及企业应用 | 主要用于快速将数据库数据暴露为 API |
当有复杂查询逻辑时，比如联表查询时，
$expand 参数实现联表查询，但需要在后端实现相应的逻辑。