REST API debate: OData vs GraphQL vs ORDS

Industry REST API

debate: OData vs

GraphQL vs ORDS

Progress DataDirect Partner Summit

© 2016 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.2

Agenda

Introduction to standard APIs to query data

Contrast the APIs for adoption in analytics and data management tools

Examples

What you should with this info?


REST is great, BUT from an analytics and data management perspective...

It’s a style – not a standard

Metadata support?

Limited querying capabilities



OData GraphQL ORDS

An open protocol to allow the

creation and consumption of

queryable and interoperable

RESTful APIs in a simple and

standard way.

• Started by Microsoft in 2007

• Ratified as an OASIS standard

on February, 2014

• Approved for release by

ISO/IEC on Feburary, 2017

Data query language for APIs

developed internally at Facebook in

2012 before public release in 2015.

GraphQL provides a complete and

understandable description of the

data in your API, gives clients the

power to ask for exactly what they

need and nothing more, makes it

easier to evolve APIs over time, and

enables powerful developer tools.

Oracle REST Data Services

(ORDS) is a powerful tool that

enables developers with SQL and

other database skills to build

enterprise class, data access APIs

to Oracle Databases that today’s

modern, state-of-the-art application

developers want to use, and indeed

increasingly demand to use, to build

applications.

60 Groups at Oracle including

Oracle RDBMS, TimesTen, and

NoSQL



OData GraphQL ORDS

Standard query

capabilities

Yes Yes Yes

Writes Yes Yes Yes

Surfacing metadata Yes Yes Yes

Maturity of specification Yes No Yes

API versioning /

maintenance

Yes No Yes



OData GraphQL ORDS

Delta Response (CDC) Yes No No

Transactions Yes, change sets No Yes, SQL pass through

Open Source

Community

Yes Yes No

Client libraries Yes Limited No

Extensible Yes Yes No

Bulk data Yes (Batch Read/Write) No Yes (Load)

Standard Query Capabilities


Standard query capabilities

Operations OData GraphQL ORDS

Filtering Yes No Yes

Ordering Yes No Yes

Aggregation No No No

Joining Yes Yes No

Paging Yes No Yes

Writes


Writes

OData GraphQL ORDS

HTTP Operations

Writes happen via HTTP POST,

PATCH, and DELETE

operations. Data to be

inserted/changed is included in

the payload.

Mutations

A mutation is an operation that

“mutates” the underlying data

system. Mutations are how you

create, read, update, or delete

(CRUD) data.

Handlers

ORDS will auto-generate

handlers to perform basic CRUD

operations on single tables or

views. These include query all

rows, query individual row, insert

single row, bulk insert, update,

and return metadata.

Surfacing Metadata


Surfacing Metadata

Operations OData GraphQL ORDS

Schema Metadata Yes Yes Yes

Object Metadata Yes Yes Yes

Object

Details

Data Types Yes Yes Yes

Scale/Precision Yes No No

Read/Write No No No

Unique No No No

Primary Keys Yes No Yes

Description Yes Yes Yes

Nullability Yes Yes No

API Versioning and Maintenance


API versioning and maintenance

GraphQL has positioned itself to take care of the headaches associated with API

versioning and maintenance

The biggest problem leading to this headache with Rest APIs is that all of the fields are

returned when you query an endpoint

• API developers have no window into whether or not clients are relying on information in

specific fields

• Client developers must process all of the fields returned even if they do not need the

information

Solved this problem by forcing clients to specify exactly which fields they require

• API developers can proactively reach out to known consumers of fields to migrate off of

deprecated fields

• Response includes information about which fields are deprecated


API versioning and maintenance

OData provides similar functionality

• Does support providing select list to limit the number of fields returned to those needed by

application

– This reduces response size and processing in application

• Does not provide a mechanism to indicate that fields are deprecated

OData is more flexible in that queries can be easily written to return all fields

OData is adding schema versioning to the specification to deal with this problem


Examples

Metadata


OData

serviceRoot/$metadata


GraphQL

Obtain metadata by

writing GraphQL

queries against

predefined types

• __schema

• __type


ORDS

HTTP GET

https://server:port/ords/crm/opportunities/{id}

Queries


OData – return all accounts

HTTP GET serviceRoot/ACCOUNTS


GraphQL - return all accounts

HTTP POST


ORDS - return all accounts

HTTP GET https://server:port/ords/ords-test/metadata-catalog/account

Queries | Inner Join


OData – return all opportunities for an account

HTTP GET <OData service root

url>/ACCOUNTS?$expand=OPPORTUNITIES($select=NAME,AMOUNT)


GraphQL - return all opportunities for an account

HTTP POST


ORDS – return all opportunities for an account

Must define handler to generate response in PL/SQL


ORDS – return all opportunities for an account

HTTP GET https://server:port/ords/ords-test/demo/test

Queries | Order By


OData - orderBy

HTTP GET serviceRoot/OPPORTUNITIES?$orderBy=name


GraphQL - orderBy

HTTP POST


ORDS - orderBy

HTTP GET https://server:port/ords/crm/demo/opportunity/q="$orderby": {“name":

“ASC"}


What you should do with this info?


Our recommendations for analytics and data management

OData GraphQL ORDS

BUY

Generally recommend supporting

OData as a consumer and in an

open analytics strategy for

producers.

Bulk data is not yet supported, but

there are data management tools

adopting it today for sources that

support OData exclusively.

HOLD

GraphQL remains very new and it

certainly addresses some of the

challenges in working across

different REST APIs.

HOLD

ORDS appears to be database

centric today and not yet widely

adopted by the vast portfolio of

SaaS applications.

We will continue to serve on the

OData technical committee to drive

the specification forward for our

partners.

We will continue to monitor

adoption and research how we can

leverage the popular concepts to

deliver improved API connectors.

We will continue to monitor adoption

and continue to research where

support for it can improve the

experience for our partners.

REST API debate: OData vs GraphQL vs ORDS

Technology

Transcript of REST API debate: OData vs GraphQL vs ORDS