Что такое API? Короткое и простое объяснение

Тема API очень интересная и большая, поэтому я разделил материал на три части, каждая из которых рассчитана на свою аудиторию. Если только начинаешь разбираться в этом вопросе, то читай все по порядку. А если что-то знаешь, то выбирай ту часть, которая тебя интересует.

1. Простое объяснение API (эта статья 👇)
2. Лучший фреймворк для API
3. Пишем API используя FastAPI (скоро)
4. Пишем API с помощью ChatGPT (скоро)
5. Инструменты тестирования API (скоро)
6. Зарабатываем деньги на API (скоро)

Итак, разбираемся…

Что такое API

API или Application Programming Interface переводится как Программный Интерфейс Приложения. Никто из разработчиков не использует сокращение ПИП 😆, в общении и в документации все говорят “АПИ”, часто с ударением на первую букву. В статье дальше используем просто “API”.

Профессионалы так и определяют API, как сервисный контракт между двумя приложениями. То есть, нормальный такой договор, в котором прописано, как приложения (программы) должны взаимодействовать друг с другом, как им формулировать свои запросы и что ожидать в качестве ответов. Кстати, хорошие разработчики всегда описывают всё это в документации к API.

Помимо нормальной документации, вот еще важные характеристики хорошего API:

• Легко понять, что и как в нем работает
• Легко пользоваться, даже без документации
• Трудно воспользоваться неправильно (защита от дурака)
• Легко читать и поддерживать код, где используется API
• Достаточно мощный для удовлетворения требований
• Легко масштабировать и наращивать функционал
• Соответствует ожиданиям пользователей

Как работают API?

Обычно работа API объясняется как взаимодействие клиента и сервера. Приложение, отправляющее запрос, называется клиентом, а приложение, отправляющее ответ, называется сервером. API обеспечивает взаимодействие между сервисами посредством циклов “запрос-ответ”. Циклы могут требовать или не требовать подключения к Интернету.

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

Протоколы API

В начале 2000-х годов существовало только два реальных протокола API, о которых должны были знать большинство разработчиков: SOAP и REST. Однако в последние годы появилось много новых протоколов, такие как новые реализации RPC, GraphQL, Thrift и прочих. Чуть подробнее о некоторых из них ниже.

SOAP

SOAP (Simple Object Access Protocol), или простой протокол доступа к объектам, использует XML файлы для передачи данных между веб-службами. XML файлы передаются по HTTP/HTTPS. Также SOAP обеспечивает определенную гибкость, позволяя передавать данные по другим протоколам, таким как Transmission Control Protocol (TCP), Simple Mail Transport Protocol (SMTP), User Data Protocol (UDP) и т.д.

Xотя SOAP по-прежнему остается наиболее распространенным и стабильным, его популярность в последнее время уступает новым протоколам.

RPC

RPC (Remote Procedure Call) или система удаленного вызова процедур - это целая группа способов, описывающих как различные компьютеры могут взаимодействовать друг с другом. Такая система существует еще с 1970-х годов. Если коротко, то клиент выполняет функцию (или процедуру) на сервере, и сервер отправляет результат обратно клиенту. Технически, тот же протокол SOAP является примером RPC.

В настоящее время используются следующие реализации протокола RPC:

• JSON-RPC, созданный в середине 2000-х годов, широко использует возможности формата JSON, но поддерживает лишь небольшой набор команд, и не предлагает такой гибкости, как другие протоколы. Впрочем, если у тебя будет простой сценарий использования API, то этот протокол может быть нормальным решением.
• XML-RPC отличается от JSON-RPC только тем, что данные передаются в виде XML файлов. Для создания запросов и ответов используется встроенная лексика XML. Клиент определяет процедуру и параметры в запросе, а сервер посылает ответ, в котором могут быть данные или же описание ошибки.
• gRPC протокол еще новее, он был опубликован Google в 2015 году, и также использует HTTP в качестве транспортного уровня. Для передачи данных используется формат ProtoBuff. В отличие от других протоколов, gRPC позволяет разработчикам самим определять такие вызовы функций, которые им нужны, а не выбирать из заранее определенных вариантов (как, например, GET и PUT в случае с REST).

REST

REST (Representational State Transfer) или передача репрезентативного состояния. Тут нужно сразу пояснить, что REST - это не протокол, то есть, у него нет четких и общепринятых правил. REST - это просто подход или, другими словами, набор рекомендаций разработчику о том, как лучше организовать взаимодействие компонентов его приложения в сети. Поэтому в интернете ты найдешь описание самых разных способов как реализовать эти рекомендации, какие методы использовать, какой код возвращать и т.п., в зависимости от ситуации.

Главными особенностями REST API являются то, что каждый запрос (REST-запрос) клиента к серверу уже содержит в себе всю информацию о том, что клиент хочет получить в ответе (желаемом представительном состоянии) от сервера, и что сервер не обязан сохранять клиентские данные (информацию о клиентской сессии) между разными запросами.

Клиентские запросы к серверу аналогичны URL-адресам, которые ты вводишь в браузере для открытия веб-сайта. Ответ от сервера представляет собой простые данные без графического отображения веб-страницы.

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

1. Модель клиент-сервер. Приложение должно использовать архитектуру клиент-сервер. Отделение потребностей клиента от потребностей сервера с данными повышает переносимость кода и масштабируемость всего приложения.
2. Отсутствие состояния. В период между запросами клиента никакая информация о состоянии клиента на сервере не хранится. Все запросы должны быть составлены так, чтобы сервер получил всю необходимую для выполнения запроса информацию.
3. Кэширование. Клиенты могут кэшировать ответы сервера. Ответы сервера, в свою очередь, должны иметь явное или неявное обозначение как кэшируемые или некэшируемые для предотвращения получения клиентами устаревших или неверных данных.
4. Унификация интерфейса. Применение принципа общности к интерфейсу компонентов упрощает архитектуру системы и улучшает прозрачность взаимодействия компонентов. Но может снижать эффективность, поскольку информация передается только в стандартной форме.
5. Многослойная система. Применение промежуточных серверов (“слоев” в иерархической структуре сети) способно повысить масштабируемость за счёт балансировки нагрузки и распределённого кэширования.
6. Код по запросу. REST позволяет расширить функциональность клиента путем загрузки и выполнения кода в виде апплета или скрипта. Это упрощает клиента, поскольку можно уменьшить количество функций, которые нужно реализовать заранее.

К преимуществам REST можно отнести надёжность, производительность (за счёт кэша), масштабируемость, легкость использования, поддержки и адаптации к возникающим новым требованиям.

GRAPHQL

GraphQL (Graph Query Language), или язык запросов к графам, был разработан в Facebook и выпущен в 2015 году. Он представляет собой попытку преодолеть некоторые ограничения и несовершенства REST.

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

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

APACHE THRIFT

Apache Thrift, как и GraphQL, создан в компании Facebook. Он был разработан с упором на две основные цели: обеспечение взаимодействия с сервисами, написанными на разных языках, и масштабируемость.

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

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

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

Где используются API

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

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

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

Теперь, когда мы разобрались, что такое API и как всё это работает, давай посмотрим на инструменты, с помощью которых можно быстро и эффективно написать свой API.

Часть 2 - Как написать свой API - уже совсем скоро!

Часть 3 - Как заработать на API - ещё работаю над статьей.

😎