Сравнение стандартных API и сервисов для запроса данных через Интернет для аналитики, интеграции и управления данными.

Джефф Лейнбах, старший инженер-программист в Progress, и Сайкришна Теджа Бобба, проповедник разработчиков в Progress, провели это исследование, чтобы помочь вам решить, какой стандартный API следует рассмотреть для внедрения в ваше приложение или инструмент аналитики / управления данными. Мы сравнили различия между OData, GraphQL и ORDS, которые представляют собой стандартные API-интерфейсы и службы для запроса и обновления данных через Интернет. Основное внимание уделяется обеспечению взаимодействия между API-интерфейсами для аналитики, интеграции и управления данными.

Мы отслеживали эти темы на основе многочисленных обсуждений на отраслевых мероприятиях, таких как AWS re: Invent, Oracle OpenWorld, Dreamforce, API World и других. Progress также имеет богатый опыт в разработке и внесении вклада в стандарты доступа к данным, включая ODBC, JDBC, ADO.NET, а теперь и OData (REST), и был первым членом, присоединившимся к Техническому комитету OData.

Что такое ОТДЫХ?

REST (передача репрезентативного состояния) или веб-службы RESTful - это один из способов обеспечения взаимодействия между компьютерными системами в Интернете. Веб-службы, совместимые с REST, позволяют запрашивать системы для доступа и управления текстовыми представлениями веб-ресурсов, используя унифицированный и предопределенный набор операций без сохранения состояния. Реализации RESTful используют такие стандарты, как HTTP, URI, JSON и XML.

Важно отметить, что REST - это архитектурный стиль, а не стандарт.

Стандартные API для запроса данных через Интернет

OData

Первоначально разработанный Microsoft в 2007 году, OData представляет собой стандартный REST API OASIS и используется такими компаниями, как Microsoft, SAP, CA, IBM и Salesforce. Он позволяет создавать и использовать RESTful API с возможностью запроса и взаимодействия простым и стандартным способом. OData предоставляет вам богатый набор возможностей запросов и быстро завоевывает популярность благодаря своему подходу с открытым исходным кодом, а также своей исключительной масштабируемости.

GraphQL

GraphQL - это язык запросов к данным, разработанный внутри Facebook в 2012 году до публичного выпуска в 2015 году, который используется в таких компаниях, как Facebook, Shopify и Intuit. GraphQL предоставляет полное и понятное описание данных в вашем API, дает клиентам возможность запрашивать именно то, что им нужно, упрощает развитие API с течением времени и предоставляет мощные инструменты разработчика.

ЗАКАЗЫ

ORDS (Oracle REST Data Services) - это сервис Oracle REST, который обеспечивает аналогичную стандартизацию для Oracle-ориентированных приложений. Он позволяет разработчикам с SQL и другими навыками работы с базами данных создавать API-интерфейсы доступа к данным корпоративного класса для Oracle Database, которые современные современные разработчики приложений хотят использовать и, действительно, все чаще используют для создания приложений. Шестьдесят групп в Oracle используют ORDS, включая Oracle Database, Times Ten и NoSQL.

В отличие от стандартных API

Рисунок 1

Критерии сопоставления стандартных API-интерфейсов на рисунке 1 основаны на достижении взаимодействия с несколькими источниками данных. В этом сравнении следует отметить зрелость спецификации. Несмотря на то, что популярность GraphQL становится все более популярной, остаются вопросы относительно зрелости для широкого распространения, передовых методов и инструментов.

При управлении версиями / обслуживанием API можно подумать, что ответ «Нет» - это плохо, но на самом деле это хорошо. Это одно из преимуществ GraphQL, о котором я расскажу позже.

фигура 2

На рисунке 2 мы завершили первоначальный анализ дополнительных критериев, которые следует учитывать, и расширим эти области в будущей статье.

Стандартные возможности запросов

Рисунок 3

На рисунке 3 показаны общие критерии доступа к данным через открытые стандартные интерфейсы. OData полностью поддерживает все эти возможности запросов. Вы можете выполнять некоторые из этих операций с GraphQL и ORDS, но они не стандартизированы и не задокументированы таким образом, чтобы обеспечить совместимость.

GraphQL очень похож на REST в том, что он определяет способ взаимодействия с веб-службой, но не сообщает вам, что она делает. Таким образом, вы можете выполнять фильтрацию, упорядочивание, объединения и т. Д., Создавая функции, которые могут вызывать, но разработчик приложения должен понимать, как они работают семантически, чтобы знать, каково их поведение.

С ORDS вы можете выполнять агрегирование и объединение, но это достигается за счет создания настраиваемых функций, которые вы можете вызывать. Но приложение должно знать, что делают эти функции, чтобы понимать, как интерпретировать результаты. Нет метаданных или стандартного определения поведения, которые могли бы сказать приложению, чего ожидать.

Просмотр метаданных

Рисунок 4

На рисунке 4 сравниваются внешние метаданные, которые являются ядром приложений для аналитики и управления данными, которым необходимо программно реконструировать схемы для обеспечения взаимодействия.

Каждый из этих API-интерфейсов совершенствуется для решения этой проблемы, однако GraphQL и ORDS не сообщают вам о масштабе и точности данных, в отличие от OData. GraphQL также не сообщает вам о первичных ключах, а ORDS не сообщает о допустимости значений NULL. Эта информация важна для приложения, чтобы знать, что оно может и что не может делать с каждым конкретным полем.

Контроль версий и обслуживание API

Одна из основных проблем - это обработка обновлений приложений при изменении API при одновременном сохранении более старых версий. Самая большая проблема, приводящая к этой головной боли с REST API, заключается в том, что все поля возвращаются при запросе конечной точки. Разработчики API не могут понять, полагаются ли клиенты на информацию в определенных полях. Разработчики клиентов должны обрабатывать все возвращенные поля, даже если они не нуждаются в информации.

GraphQL решил проблему управления версиями и обслуживания API, заставив клиентов точно указывать, какие поля им требуются. Разработчики API могут заранее связаться с известными потребителями полей для миграции с устаревших полей. Ответ включает информацию о том, какие поля устарели.

OData предоставляет аналогичные функции, предоставляя список выбора, чтобы ограничить количество возвращаемых полей теми, которые необходимы приложению. Это уменьшает размер ответа и сокращает объем обработки в приложении. Однако он не предоставляет механизма, указывающего, что поля устарели.

OData более гибок в том, что запросы могут быть легко написаны для возврата всех полей. OData добавляет в спецификацию управление версиями схемы, чтобы решить эту проблему.

Примеры

Чтобы наглядно проиллюстрировать различия в работе с этими API, в следующих двух примерах кода показано, как выполнить «Упорядочить по» в GraphQL и OData.

В примере GraphQL с вызовом функции All Opportunities по названию несколько очевидно, что она делает. Однако в GraphQL нет ничего, что говорило бы вам, что вы можете передать для этих аргументов и как значения, указанные в качестве аргументов, вызывают поведение функции. И это поведение может отличаться в зависимости от реализации.

В отличие от этого OData сообщает вам, как именно он будет себя вести при использовании параметра запроса orderBy, поскольку его поведение определяется как часть спецификации.

Рекомендации

GraphQL почти похож на язык программирования, что делает его очень гибким. Это мощный инструмент, но его использование означает, что ваше приложение тесно связано с тем, как реализована конкретная служба GraphQL. Невозможно в общих чертах описать, как это работает.

GraphQL также может быть немного неудобным для людей, которые привыкли иметь дело с веб-службами, потому что для запроса данных вы не выполняете операцию GET, как вы получили бы результаты от обычной веб-службы REST. Вы выполняете POST, точно определяя, какие поля и функции вы хотите включить в ответ.

Таким образом, хотя GraphQL дает вам возможность определять по метаданным, какие поля и функции доступны, вы по-прежнему не знаете, что они означают семантически.

Устранение барьеров для входа

Эта статья в первую очередь ориентирована на потребителей API, но GraphQL имеет гораздо более низкий барьер для входа в разработку API. Если вы делаете быстрый проект, вам, вероятно, подойдет GraphQL. Но у вас все еще есть проблема, связанная с тем, что ваше приложение тесно связано с вашей реализацией.

OData действительно мощная, но с ней связано много тяжелой работы, потому что вы должны придерживаться всех правил поведения стандарта. У вас должен быть минимальный уровень поведения для совместимости с OData. Это создает больший барьер для входа для разработчиков сервисов.

Однако вы можете использовать нашу гибридную технологию для создания стандартного REST API (OData). Мы делаем всю тяжелую работу с OData, поэтому вам не нужно беспокоиться о соблюдении стандарта. Мы снизили для вас входной барьер.

Воспользуйтесь нашей гибридной технологией для создания стандартного REST API (OData). Мы делаем всю тяжелую работу с OData, поэтому вам не нужно (твитнуть)

Кроме того, существует множество клиентов OData, которые могут помочь вам быстро и легко приступить к работе со службой OData. Существует обширный список приложений, которые уже поддерживают OData, а также клиентских библиотек OData, которые могут помочь вам, если вы разрабатываете новое приложение.

Если вы хотите узнать, как встроить нашу гибридную технологию для предоставления данных через REST с помощью OData, поговорите с одним из наших экспертов по подключению данных сегодня.

Поговорите с экспертом сегодня

Этот контент изначально был размещен в Progress blog. Хотите узнать больше о технологиях и создании бизнес-приложений завтрашнего дня? Загляните в блог, чтобы узнать больше.