我在我的职业生涯中使用过很多 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 文档中的 link 属性支持 HATEOAS。其他功能包括分页、排序、过滤和关系。 JSON API 服务器生成的 JSON 文档非常冗长，包含大量嵌套属性。
GraphQL：自 2015 年以来在 Facebook 开发。specification 仍然是一个工作草案。它在 React 爱好者中很受欢迎，主要与 React 或 Vue.js 结合使用。与 GraphQL 类似的是 Falcor，也是比较新的。
虽然 GraphQL 使用 HTTP，但它不被视为 REST，而是 REST 的替代品。相反，它在单个（虚拟）JSON 文档中使用查询/响应模型。这种新模型更适合开发人员使用，但它相对于 REST 的优势是值得商榷的。鉴于其年龄尚小，生态系统尚未成熟。
为了清楚和完整起见，我会将 OpenAPI 包括在列表中，尽管它并不完全是 API 规范。这可能会让一些人感到困惑。 OpenAPI 标准是一种与语言无关的标准，用于描述和定义 API。您的 API 可以遵循上述标准之一（不包括 GraphQL），也可以使用 OpenAPI 3 进行记录。
使用 OpenAPI 等规范获得的最好的东西是围绕它们的工具 - API 文档页面的生成器、客户端 SDK 代码的生成器等。
这个标准可能是当今最常用于 API 声明、文档和代码生成的标准。它也受到云提供商（如 Amazon Web Services）在其 API 网关中的支持。
总之，OData 和 JSON API 都是 JSON 数据格式，它们在数据周围添加上下文和特征（例如链接），GraphQL 是一种完全不同的查询和变异 JSON 数据的新方法，而 OpenAPI 是声明的标准方法并记录任何 RESTful API。
我的个人意见：
如您所见，有很多 RESTful 规范，而不是单一的通用标准。我同意xumix 的观点——他们似乎都患有“这里没有发明”综合症。选择上述任何一项的好处都很小，特别是如果您的项目是中小型项目。 您的 API 实现的规范是否重要？应该不多吧。只需专注于构建一致且文档齐全的 API。
【讨论】：