OData、JsonAPI和GraphQL之间有什么区别？

在我的职业生涯中，我经常使用OData，现在，来自不同团队的同事中很少有人建议我们使用JsonAPI和GraphQL，因为它与Microsoft无关。我对这两种查询语言都没有太多经验。据我所知，OData是Salesforce、IBM和Microsoft使用的标准，它非常成熟。为什么要切换到JsonAPI和/或GraphQL？真的有好处吗？JsonAPI和GraphQL是新标准吗？基于流行度改变公共api实现似乎毫无用处，尤其是在没有大的好处的情况下

---

有人能告诉我吗？

OData是一种类似于JSON API的规范。它们都描述了创建和使用RESTful API的标准协议。GraphQL是一种完全不同的API设计方法，它指定了一种查询API资源的不同方式

• OData：自2007年起由微软设计和开发，由联合体标准化。最新版本作为国际标准提交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最初由耶胡达·卡茨于2013年5月起草。这个初稿是从Ember数据的REST适配器隐式定义的JSON传输中提取的。规范的当前稳定版本为。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），也可以使用OpenAPI3进行记录

强> OpenAPI（A.k.Savigg）< /强>：作为Linux基础的一部分开发。由谷歌、微软、IBM、SAP、甲骨文、易趣和贝宝等大型科技公司提供支持。规范的当前版本为。大多数编程语言都有实现，还有许多附加工具，如WebUI生成器等

像OpenAPI这样的规范所带来的最好的东西是围绕它们的工具——API文档页面的生成器、客户端SDK代码的生成器，等等

该标准可能是目前最常用的API声明、文档和代码生成标准。它还受到云提供商（如Amazon Web Services）在其API网关中的支持

总之，OData和JSON API都是JSON数据格式，它们在数据周围添加了上下文和特性（例如链接），GraphQL是一种完全不同的查询和修改JSON数据的新方法，OpenAPI是声明和记录任何RESTful API的标准方法

我的个人意见：

正如您所看到的，有相当多的RESTful规范，而不是单一的通用标准。我同意这一点——他们似乎都患有“非发明于此”综合症。选择上述任何一项的好处都很小，尤其是当您的项目是小型或中型的时候。

---

API实现哪种规范重要吗？可能不多。只需专注于构建一个一致且有良好文档记录的API。

GraphQL不是REST的替代品，而是版本控制可能成为问题时的替代品。他们似乎都患有NIH综合症。比如MS是邪恶的等等。