OData против GraphQL
Есть ли хорошее сравнение GraphQL и OData с точки зрения производительности, удобства использования разработчиками, сообщества и т. д. Все статьи, которые я нахожу в Интернете, очень предвзяты.
Как лучше всего вернуть большие объемные данные в формате JSON или двоичные данные?
Ответы 2
Я исследовал и также пробовал использовать как GraphQL в Dot Net, так и Odata в DotNet Web API, чтобы создать рабочую демонстрацию, и то, что я обнаружил,
- Удобство использования для разработчиков Учитывая, что у вас есть существующий WebAPI (DotNet Framework) и вы хотите перейти на GraphQL или OData-совместимый WebAPI, мой ответ - выбрать OData из-за его простой интеграции и функции Out of the Box Filter, OrderBy, Select, Expand и т. д. (См. MSFT в DotNet OData ). Если вы выберете GraphQL, вам придется проделать большую работу, например, создать тип, схему и запрос, а также реализовать преобразователь для каждого запроса.
- Представление зависит от вашей логики запроса. GraphQL и Odata Оба имеют возможность получить то, что вы запрашиваете, используя $ select в OData, а в GraphQL вы можете запросить по их соглашению о запросах.
- Разработка API с нуля, если вам нужна только одна конечная точка для всех запросов API и вы не хотите поддерживать конечную точку управления версиями, имя поля автозаполнения и тип схемы, тогда GraphQL - лучший вариант. Но доступность библиотеки GraphQL для каждой платформы и сообщества зависит от стека технологий (например, nodejs, C#, Ruby, Java и т. д.).
Да, я просмотрел и прочитал статью Telerik, в которой подробно описано. Сравнение PDF Для GraphQL и Odata Я прилагаю параллельное изображение сравнения, только вы можете выкопать подробности в Ссылке ссылки GraphQL против OData.
Стандартный API
Здесь Нет в управлении версиями / обслуживании API является положительным, что означает единую конечную точку и избавление от двух API с поддержкой версий.
Возможность запроса
Поверхностные возможности
В основном служба OData используется, когда вы хотите предоставить доступ к своей базе данных с минимальными усилиями для работы CRUD.
Однако, если вы знаете о Sharepoint REST API и Office 365 REST API, он основан на OData и предоставляет широкий спектр API. Сейчас Microsoft создает универсальный API, который называется Graph API или Microsoft Graph, который по умолчанию включен для запросов CORS и унифицированных конечных точек для запросов из Office 365, Dynamics 365, Outlook Exchange API, Onedrive API и т. д. Которые также поддерживают OData.
Я знаю, что это старый ответ, но похоже, что GraphQL теперь поддерживает фильтрацию и упорядочение. howtographql.com/graphql-js/8-filtering-pagination-and-sorti ng
Да Поддерживается OData Фильтр OOTB (из коробки) с GraphQL, используя нашу логику, которую мы можем реализовать (y)
Также не кажется хорошей идеей использовать метод POST для запроса данных. И очевидно, что объем данных, необходимых для запроса к серверу, намного больше. По примерам из Сумит Саркар статья:
Объем данных, передаваемых для выполнения запроса, в GraphQL намного больше, чем в OData. Хотя результат (ответ) тот же.
Запросы большего размера, и вы запрашиваете данные с помощью HTTP POST, который просто кажется грязным.
Это кажется грязным, но после того, как API созреет, вы получите по крайней мере некоторые настраиваемые действия на конечных точках OData, для которых вы должны указать параметры POST с целью получения специализированного набора данных. Я на 100% профессионал в области OData, но GraphQL действительно устраняет необходимость в некоторых из этих настраиваемых действий, которые существуют для обработки сложных запросов, которые вы не можете выполнить с помощью соглашений об URL-адресах.