问题：
我在职业生涯中使用过很多 OData，现在我来自不同团队的同事中很少有人建议我们迁移到 JsonAPI 和 GraphQL，因为它与 Microsoft 无关。我对这两种查询语言都没有太多经验。据我所知，OData 是 Salesforce、IBM、Microsoft 使用的标准，并且非常成熟。为什么要切换到 JsonAPI 和/或 GraphQL？有真正的好处吗？JsonAPI 和 GraphQL 是新标准吗？根据受欢迎程度更改公共 api 实现似乎没有用，尤其是在没有太大好处的情况下。
有人可以启发我吗？
答案：
OData 是与 JSON API 类似的规范。它们都描述了用于创建和使用 RESTful API 的标准协议。GraphQL 是一种完全不同的 API 设计方法，并指定了一种查询 API 资源的不同方式。
OData：
自 2007 年以来在 Microsoft 设计和开发，由 OASIS 联盟标准化。最新版本 V4 已提交给 ISO/IEC JTC 1 以作为国际标准获得批准。技术委员会 (TC) 中的公司包括 CA Technologies、Citrix、IBM、Microsoft、Progress、Red Hat、SAP 和 SDL。
有许多用于流行编程语言的库 - .NET、Java、JavaScript、PHP 和 Ruby。该规范允许动态资源，并且有一个服务文档列出了所有 API 端点供客户端发现。此外，还有一个描述架构的元数据文档。
JSON API：
JSON API 最初由 Yehuda Katz 于 2013 年 5 月起草。这个初稿是从 Ember Data 的 REST 适配器隐式定义的 JSON 传输中提取的。该规范的当前稳定版本是 1.0。JSON API 规范适用于大多数编程语言，包括客户端和服务器端。
JSON API 通过 JSON 文档中的链接属性支持 HATEOAS。其他功能包括分页、排序、过滤和关系。JSON API 服务器生成的 JSON 文档非常冗长，带有许多嵌套属性。
GraphQL：
自 2015 年以来在 Facebook 开发。该规范仍是工作草案。它在 React 爱好者中很受欢迎，主要与 React 或 Vue.js 结合使用。与 GraphQL 类似的是 Falcor，它也相对较新。
虽然 GraphQL 使用 HTTP，但它不被视为 REST，而是 REST 的替代品。相反，它在单个（虚拟）JSON 文档中使用查询/响应模型。这种新模型更适合开发人员使用，但它相对于 REST 的优势是值得商榷的。鉴于其年轻，生态系统尚未成熟。
为了清楚和完整起见，我将 OpenAPI 包括在列表中，尽管它并不完全是 API 规范。这可能会让一些人感到困惑。 OpenAPI 标准是一种与语言无关的标准，用于描述和定义 API。例如，您的 API 可以遵循上述标准之一（不包括 GraphQL），也可以使用 OpenAPI 3 进行记录。
OpenAPI（又名 Swagger）：
作为 OpenAPI Initiative 和 Linux 基金会的一部分开发。得到 Google、Microsoft、IBM、SAP、Oracle、Ebay 和 PayPal 等大型科技公司的支持。该规范的当前版本是 3.1.0。大多数编程语言都有实现，以及许多其他工具，如 Web UI 生成器等。 使用 OpenAPI 等规范获得的最好的东西是围绕它们的工具——API 文档页面的生成器、客户端 SDK 代码的生成器等。
这个标准可能是当今最常用于 API 声明、文档和代码生成的标准。它还受到云提供商（如 Amazon Web Services）在其 API 网关中的支持。
总之，OData 和 JSON API 都是 JSON 数据格式，它们在数据周围添加上下文和特征（例如链接），GraphQL 是一种完全不同的查询和变异 JSON 数据的新方法，而 OpenAPI 是声明和记录任何数据的标准方法RESTful API。
我个人的看法：
如您所见，有很多 RESTful 规范，而不是单一的通用标准。我同意 xumix 的观点——他们似乎都患有“这里没有发明”综合症。选择上述任何一项的好处都很小，特别是如果您的项目是中小型项目。您的 API 实现的规范是否重要？应该不多吧。只需专注于构建一致且记录良好的 API。
