问题:

我在职业生涯中使用过很多 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。

公众号

【超级架构师】

精彩图文详解架构方法论,架构实践,技术原理,技术趋势。



QQ群【792862318】