【API架构】REST API 行业辩论：OData vs GraphQL vs ORDS
本文比较了标准 API 和服务，以通过 Internet 查询数据以进行分析、集成和数据管理。
Progress 的高级软件工程师 Jeff Leinbach 和 Progress 的开发布道者 Saikrishna Teja Bobba 进行了这项研究，以帮助您决定在您的应用程序或分析/数据管理工具中考虑采用哪种标准 API。我们对比了 OData、GraphQL 和 ORDS 之间的区别，它们是用于通过 Internet 查询和更新数据的标准 API 和服务。重点是实现跨 API 的互操作性，以进行分析、集成和数据管理。
我们一直在根据 AWS re:Invent、Oracle OpenWorld、Dreamforce、API World 等行业活动中的大量讨论跟踪这些主题。 Progress 在数据访问标准（包括 ODBC、JDBC、ADO.NET 和现在的 OData (REST)）的开发和贡献方面也拥有丰富的传统，并且是第一个加入 OData 技术委员会的成员。
什么是 REST？
REST（表示状态传输）或 RESTful Web 服务是在 Internet 上的计算机系统之间提供互操作性的一种方式。符合 REST 的 Web 服务允许请求系统使用一组统一且预定义的无状态操作来访问和操作 Web 资源的文本表示。 RESTful 实现使用 HTTP、URI、JSON 和 XML 等标准。
重要的是要注意 REST 是一种架构风格，而不是标准。
通过 Internet 查询数据的标准 API
OData
OData 最初由 Microsoft 于 2007 年开发，是一种 OASIS 标准 REST API，建立在 Microsoft、SAP、CA、IBM 和 Salesforce 等公司之间。它允许以简单和标准的方式创建和使用可查询和可互操作的 RESTful API。 OData 为您提供了一组丰富的查询功能，并因其开源方法以及出色的可扩展性而迅速获得支持。
GraphQL
GraphQL 于 2012 年在 Facebook 内部开发，在 2015 年公开发布之前，是一种部署在 Facebook、Shopify 和 Intuit 等公司的数据查询语言。 GraphQL 为您的 API 中的数据提供了完整且易于理解的描述，使客户能够准确地询问他们需要什么，使 API 更容易随着时间的推移而发展，并支持强大的开发人员工具。
ORDS
ORDS（Oracle REST 数据服务）是 Oracle REST 服务，它为以 Oracle 为中心的应用程序提供类似的标准化。它使具有 SQL 和其他数据库技能的开发人员能够构建对 Oracle 数据库的企业级数据访问 API，当今的现代、最先进的应用程序开发人员希望使用这些 API，并且确实越来越需要使用这些 API 来构建应用程序。 Oracle 的 60 个小组使用 ORDS，包括 Oracle Database、Times Ten 和 NoSQL。
对比标准 API
图 1
对比图 1 中的标准 API 的标准是基于实现与多个数据源的互操作性。 关于这种比较需要注意的一点是规范的成熟度。 尽管 GraphQL 越来越受欢迎，但在广泛采用、最佳实践和工具方面的成熟度仍然存在问题。
在 API 版本控制/维护下，您会认为“否”是不好的，但实际上是好的。 这是 GraphQL 的优势之一，我稍后会介绍。
图 2
在图 2 中，我们完成了对要考虑的其他标准的初步分析，并将在以后的文章中扩展这些领域。
标准查询能力
图 3
图 3 突出显示了通过开放标准接口访问数据的通用标准。 OData 全面支持所有这些查询功能。您可以使用 GraphQL 和 ORDS 执行其中一些操作，但它们没有标准化或以实现互操作性的方式记录。
GraphQL 与 REST 非常相似，因为它定义了与 Web 服务交互的方式，但它并没有告诉你服务的作用。因此，您可以通过创建可以调用的函数来进行过滤、排序和连接等操作，但应用程序开发人员必须了解它们在语义上的工作方式才能知道它们的行为是什么。
使用 ORDS，您可以进行聚合和连接，但这是通过创建您可以调用的自定义函数来完成的。但是应用程序必须知道这些函数做了什么才能理解如何解释结果。没有元数据或标准行为定义可以告诉应用程序会发生什么。
呈现元数据
图 4
图 4 比较了表面元数据，这是分析和数据管理应用程序的核心，需要以可互操作的方式以编程方式对模式进行逆向工程。
这些 API 中的每一个都在努力解决这个问题，但是 GraphQL 和 ORDS 不会告诉您数据的规模和精度，而 OData 会。 GraphQL 也不会告诉您主键，ORDS 也不会告诉您可空性。此信息对于应用程序能够知道它可以对每个特定字段做什么和不能做什么很重要。
API 版本控制和维护
一个令人头疼的问题是在 API 更改时处理应用程序的更新，同时还要维护旧版本。导致 REST API 令人头疼的最大问题是，当您查询端点时会返回所有字段。 API 开发人员无法了解客户是否依赖特定领域的信息。客户端开发人员必须处理所有返回的字段，即使他们不需要这些信息。
GraphQL 通过强制客户端准确指定他们需要哪些字段来解决 API 版本控制和维护问题。 API 开发人员可以主动联系已知的字段使用者，以迁移已弃用的字段。响应包括有关哪些字段已弃用的信息。
OData 通过提供一个选择列表来将返回的字段数限制为应用程序所需的字段数，从而提供类似的功能。这减少了应用程序中的响应大小和处理。但是，它没有提供一种机制来指示字段已被弃用。
OData 更加灵活，因为可以轻松编写查询以返回所有字段。 OData 正在将模式版本控制添加到规范中以解决此问题。
例子
为了直观地说明使用这些 API 的差异，以下两个代码示例展示了如何在 GraphQL 和 OData 中执行“排序依据”。
在 All Opportunities 函数调用的 GraphQL 示例中，从名称上可以看出它的作用。 但是，GraphQL 中没有任何内容可以告诉您可以为这些参数传递什么以及指定为参数的值如何导致函数运行。 并且这种行为在不同实现的基础上可能会有所不同。
相比之下，当您使用 orderBy 查询参数时，OData 会准确地告诉您它的行为方式，因为它的行为被定义为规范的一部分。
建议
GraphQL 几乎就像一种编程语言，这使得它非常灵活。它功能强大，但使用它意味着您的应用程序与特定 GraphQL 服务的实现方式紧密耦合。没有办法笼统地描述它是如何工作的。
对于习惯于处理 Web 服务的人来说，GraphQL 也可能有点尴尬，因为为了查询数据，您不需要执行 GET 操作，这就是您从普通 REST Web 服务获取结果的方式。您执行 POST，准确定义要包含在响应中的字段和函数。
因此，尽管 GraphQL 使您能够从元数据中确定哪些字段和函数可用，但您仍然不知道它们在语义上的含义。
消除进入障碍
本文主要关注 API 使用者，但 GraphQL 开发 API 的门槛要低得多。如果你正在做一个快速的项目，GraphQL 可能是要走的路。但是你仍然有你的应用程序与你的实现紧密耦合的问题。
OData 确实很强大，但是伴随着很多繁重的工作，因为您必须遵守标准的所有行为。您必须符合 OData 的最低行为级别。这为服务开发人员设置了更大的进入壁垒。
但是，您可以利用我们的混合技术来生成标准
REST API (OData)。 我们利用我们的混合技术完成所有繁重的工作，以生成标准的 REST API (OData)。 我们使用 OData 完成所有繁重的工作，因此您不必担心遵守标准。 我们为您降低了进入门槛。
此外，还有许多 OData 客户端可以帮助您快速轻松地启动和运行 OData 服务。 如果您正在开发一个新的应用程序，有很多已经支持 OData 的应用程序，以及可以为您提供帮助的 OData 客户端库。
如果您想了解如何嵌入我们的混合技术以使用 OData 通过 REST 公开数据，请立即与我们的一位数据连接专家交谈。
原文：https://www.progress.com/blogs/rest-api-industry-debate-odata-vs-graphq…
- 108 次浏览