API — это абсолютная инновация для Интернета и многих разработчиков. Цифровой мир без API невообразим! Почему? Потому что API берут на себя работу. Обмен информацией стал намного проще и эффективнее. Но что, если дело дойдет до написания собственного API? — Ну, есть много разных типов API. Но какой из них лучше?

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

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

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

Итак… какой тип API лучше всего подходит для этой работы?

А как же отдых?

REST API (передача состояния представления) или RESTful API — это архитектурный стиль, который следует определенным ограничениям, определяемым этим архитектурным стилем REST. С REST API вы можете взаимодействовать с веб-сервисами RESTful.

Такой REST API работает с HTTP, что означает, что вы можете работать с глаголами HTTP, такими как POST, GET и другими. Принцип REST заключается в том, что клиент отправляет HTTP-запрос с операцией, которую он хочет выполнить. Таким образом, клиент может читать и манипулировать ресурсами (информацией). Эти ресурсы являются идентифицируемыми. Клиент также может делать это с помощью таких гипермедиа, как изображения. [1]

Звучит отлично? Нисколько…

Когда клиент делает запрос, он получает всю информацию о запрашиваемом ресурсе сервера. Но клиентам нужна только конкретная информация. Эта проблема называется избыточной выборкой: клиент получает больше информации, чем запросил. [2] Это может стоить больших проблем с производительностью. Особенно, если вы посмотрите на мобильные устройства. Это будет стоить много трафика данных.

Это не лучшее решение для нашего примера.

Может быть, SOAP?

SOAP (Simple Object Access Protocol) — это стандартная система протоколов с протоколами для доступа к веб-сервисам через HTTP. Он определяет, как веб-службы взаимодействуют друг с другом или с другими клиентами. SOAP предназначен для работы с разными приложениями, написанными на разных языках программирования. [3]

API с SOAP соответствует высоким стандартам безопасности, поскольку поддерживает SSL и имеет встроенное соответствие требованиям ACID. Как и в REST, вы можете использовать глаголы HTTP для взаимодействия с API. [4]

Проблема с API-интерфейсами SOAP заключается в том, что для их производительности требуется большая пропускная способность и вычислительная мощность. К сожалению, это большой минус, когда клиенты в основном пользуются мобильными телефонами. Еще одним недостатком является то, что единственным поддерживаемым форматом сообщений является XML. Это означает, что он менее гибок, чем другие технологии API. [4]

В общем, для нашего примера, когда нам нужна хорошая производительность API, SOAP не подойдет. И вы не можете выбрать формат сообщения, который вы хотите.

Или GraphQL?

Другая технология API называется GraphQL. Для сравнения, GraphQL существует с 2015 года. GraphQL — это язык запросов для API, предназначенный для получения именно той информации, которая вам нужна. GraphQL работает с запросами для получения и отправки информации клиенту. Кроме того, определены различные поля, содержащие информацию, которую клиент может запросить. GraphQL различается между уникальными ресурсами. Например, вы можете использовать идентификаторы для правильной идентификации ресурса. При использовании GraphQL вы можете использовать практически любой язык программирования, который вам нужен, и вы можете решить, в каком формате клиент запрашивает и получает информацию. [5]

Короче говоря, большое преимущество API GraphQL заключается в том, что клиент получает только ту информацию, которая ему нужна или запрошена. API GraphQL способен идентифицировать ресурс и отправляет только запрошенную информацию о запрошенном ресурсе. Это означает, что API-интерфейсы GraphQL не имеют проблем с избыточной или недостаточной выборкой. В результате производительность этого API может быть выше, чем у REST или SOAP API. [5]

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

Сравнение между REST, SOAP и GraphQL — это лишь небольшое сравнение. Есть еще много вещей, которые следует учитывать при выборе «правильной» API-технологии для вашего проекта. Личные предпочтения и знания также важны для вашего решения. Что касается примера, у некоторых программистов может быть другая точка зрения. Не существует «правильной» технологии API. Так что это полностью зависит от вас, что вы хотите использовать и что вам удобно.

Вот некоторые ресурсы:

[1] Что такое REST API? (н. д.). Красная Шапка. Посещено 18 марта 2022 г. по адресу https://www.redhat.com/en/topics/api/what-is-a-rest-api.

[2] Раздражающие проблемы с REST. (О. Д.). Узнатьграф. Посещено 18 марта 2022 г., фон https://leapgraph.com/what-graphql-solves/

[3] Уокер, А. (2022, 12 февраля). Учебное пособие по веб-службам SOAP: что такое протокол SOAP? ПРИМЕР. Гуру99. Abgerufen am 19. März 2022, фон https://www.guru99.com/soap-simple-object-access-protocol.html

[4] SOAP, REST и JSON — сравнение 2021 года. (2021, 5 марта). Блог Raygun. Abgerufen am 19. März 2022, фон https://raygun.com/blog/soap-vs-rest-vs-json/#table

[5] GraphQL | Язык запросов для вашего API. (О. Д.). ГрафQL. Abgerufen am 19. März 2022, фон https://graphql.org/