Подтвердить что ты не робот

В чем разница между OData, JsonAPI, GraphQL?

Я использовал OData в своей карьере совсем немного, и теперь немногие из моих коллег из разных команд рекомендовали нам перейти на JsonAPI и GraphQL, поскольку они не привязаны к Microsoft. У меня нет большого опыта в обоих этих языках запросов. Насколько я знаю, OData - это стандарт, используемый Salesforce, IBM, Microsoft и очень зрелый. Почему нужно переключиться на JsonAPI и/или GraphQL? Есть ли реальная выгода? Является ли JsonAPI и GraphQL новым стандартом? Изменение общедоступных api-реализаций, основанных на популярности, кажется бесполезным, особенно когда нет большой выгоды.

Может кто-нибудь, пожалуйста, просветит меня?

4b9b3361

ОТВЕТЫ

Ответ 1

OData - одна из спецификаций, аналогичных JSON API. Оба они описывают стандарт для создания и использования RESTful API. GraphQL - это новый подход к разработке API, который определяет другой способ запроса ресурсов API.

  • OData: Разработано и разработано в Microsoft с 2007 года, стандартизировано консорциумом OASIS. Последняя версия V4 представлена ISO/IEC JTC 1 для утверждения в качестве международного стандарта. Компании, входящие в технический комитет (TC), включают CA Technologies, Citrix, IBM, Microsoft, Progress, Red Hat, SAP и SDL.

    Существует ряд библиотек для популярных языков программирования -.NET, Java, JavaScript, PHP и Ruby. Спецификация позволяет динамические ресурсы и сервисный документ, в котором перечислены все конечные точки API для клиентов. Кроме того, есть документ метаданных, описывающий схему.

  • JSON API: JSON API был изначально разработан Иегудой Кацем в мае 2013 года. Этот первый черновик был извлечен из транспорта JSON, неявно определенного REST-адаптером Ember Datas. Текущая стабильная версия спецификации 1.0. Спецификация JSON API реализована для большинства языков программирования, как для клиентской, так и для серверной сторон.

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

  • GraphQL: разрабатывается в Facebook с 2015 года. Спецификация все еще находится в рабочем состоянии. Он довольно популярен среди фанатов React и в основном используется в сочетании с React или Vue.js. Сходным с GraphQL является Falcor, который также является относительно новым.

    Хотя GraphQL использует HTTP, он не считается REST, скорее, альтернативой REST. Вместо этого он использует модель запроса/ответа в одном (виртуальном) документе JSON. Эта новая модель более приятна для разработчиков, но ее преимущества перед REST спорны. Учитывая ее молодой возраст, экосистема еще не созрела.

Для ясности и полноты я включу в список OpenAPI, хотя это не совсем спецификация API. Это может сбивать с толку некоторых людей. Стандарт OpenAPI - это независимый от языка стандарт для описания и определения API. Ваш API может соответствовать одному из вышеуказанных стандартов (исключая GraphQL), а также документироваться, например, с помощью Swagger 3.

  • OpenAPI (он же Swagger): разработан как часть инициативы OpenAPI и Linux Foundation. При поддержке крупных технологических компаний, таких как Google, Microsoft, IBM, SAP, Oracle, Ebay и PayPal. Текущая версия спецификации - 3.0.2. Существуют реализации для большинства языков программирования, а также множество дополнительных инструментов, таких как генераторы веб-интерфейса и т.д.

Лучшее, что вы можете получить с такими спецификациями, как Swagger, - это инструменты вокруг них - генераторы страниц документации API, генераторы клиентского кода SDK и т.д.

Этот стандарт, вероятно, наиболее часто используется сегодня для документации API и генерации кода. Он также поддерживается облачными провайдерами, такими как Amazon Web Services, в их API-шлюзе (только v2).

Мое личное мнение:

Как видите, существует довольно много спецификаций RESTful, а не единого универсального стандарта. Я согласен с xumix здесь - они все, кажется, страдают от синдрома "Не изобретено здесь". Преимущества выбора любого из вышеперечисленных невелики, особенно если ваш проект маленький или средний. Имеет ли значение, какую спецификацию реализует ваш API? Наверное, не очень. Просто сфокусируйтесь на создании последовательного и хорошо документированного API.