Comparing Standard APIs for Internet Data Query: OData, GraphQL, and ORDS

What is REST?

REST (Representational State Transfer) or RESTful web services provide a way for computer systems on the Internet to interoperate; a REST‑compliant service lets a client use a predefined set of stateless operations to access and manipulate textual representations of web resources using standard protocols such as HTTP, URI, JSON, and XML.

It is important to note that REST is an architectural style, not a standard.

Standard APIs for Querying Data over the Internet

OData

Originally developed by Microsoft in 2007, OData is an OASIS‑standard REST API backed by companies such as Microsoft, SAP, CA, IBM, and Salesforce. It enables the creation and consumption of queryable, interoperable RESTful APIs, offering a rich set of query features, an open‑source approach, and strong scalability.

GraphQL

Created internally at Facebook in 2012 and open‑sourced in 2015, GraphQL is a data‑query language used by companies like Facebook, Shopify, and Intuit. It provides a complete, understandable description of the data in an API, allowing clients to request exactly what they need, facilitating API evolution, and supporting powerful developer tooling.

ORDS

Oracle REST Data Services (ORDS) is Oracle’s REST offering that standardizes data‑access APIs for Oracle‑centric applications. It enables developers with SQL and database expertise to build enterprise‑grade data‑access APIs for Oracle databases, and is used by dozens of Oracle product groups.

Comparison of Standard APIs

Figure 1

Figure 1 compares the APIs based on interoperability with multiple data sources. Maturity is a key factor: while GraphQL is gaining popularity, it still lags behind in widespread adoption, best‑practice guidance, and tooling.

In API versioning/maintenance, a “no” answer may actually be beneficial—this is one of GraphQL’s strengths, discussed later.

Figure 2

Figure 2 shows a preliminary analysis of additional standards that will be explored in future articles.

Standard Query Capabilities

Figure 3

Figure 3 highlights the common query features available through open‑standard interfaces. OData fully supports all of these features, whereas GraphQL and ORDS can perform some of them but lack standardized, interoperable documentation.

GraphQL resembles REST in that it defines how to interact with web services, but it does not prescribe the service’s behavior; developers must understand the semantics of custom functions for filtering, sorting, and joining.

ORDS allows aggregation and joins via custom functions, but the application must know what those functions do; there is no metadata or standard behavior definition to guide interpretation.

Metadata Presentation

Figure 4

Figure 4 compares surface‑level metadata, which is essential for analytics and data‑management tools that need to programmatically reverse‑engineer schemas in an interoperable way.

All three APIs attempt to address this, but GraphQL and ORDS do not convey data scale, precision, primary keys, or nullability—information that OData does provide and that is crucial for applications to understand field capabilities.

API Versioning and Maintenance

A common pain point is handling application updates when an API changes while still supporting older versions. REST APIs often return all fields, making it hard for developers to know which fields clients actually depend on.

GraphQL mitigates this by forcing clients to specify exactly which fields they need, allowing API providers to deprecate fields intentionally and communicate deprecation information in responses.

OData limits the number of returned fields through a $select clause, reducing response size, but it does not provide a built‑in mechanism to indicate deprecated fields.

OData is flexible because queries can be written to return all fields, and the specification is adding schema versioning to address this limitation.

Examples

To illustrate the differences, the following two code snippets show how to perform an “orderBy” operation in GraphQL and OData.

The GraphQL example for the All Opportunities function makes its purpose clear from the name, but GraphQL provides no information about what arguments can be passed or how they affect execution, and behavior may vary between implementations.

In contrast, OData’s $orderBy parameter precisely defines its behavior as part of the specification.

Recommendations

GraphQL is almost a programming language, offering great flexibility but tightly coupling your application to a specific GraphQL service implementation.

For developers accustomed to traditional web services, GraphQL can feel awkward because data queries use POST rather than GET, which is typical for REST services.

Although GraphQL lets you discover available fields and functions from metadata, you still lack semantic meaning for those elements.

Lowering the Barrier to Entry

This article focuses on API consumers, but the barrier to developing GraphQL APIs is relatively low; for quick projects, GraphQL may be the way to go, though it still creates tight coupling.

OData is powerful but requires adherence to many mandatory behaviors, raising the entry barrier for service developers.

However, you can use our hybrid technology to generate a standard REST API (OData).

We handle the heavy lifting of conforming to the OData standard, reducing your workload and lowering the entry barrier.

Many OData client libraries are available to help you quickly start and run OData services; if you are building a new application, numerous tools already support OData and can assist you.

If you want to learn how to embed our hybrid technology to expose data via OData over REST, contact one of our data‑connection experts immediately.

Thank you for following, sharing, liking, and watching.