.webp)
.webp)
API расшифровывается как Application Programming Interface (программный интерфейс приложения). Что же это такое?
По сути, это описание способов взаимодействия между программами, как они могут общаться и передавать данные друг другу.
Рассмотрим пример из жизни:
Приходя в ресторан вы взаимодействуйте с официантом - можете попросить меню, сделать заказ, попросить принести счет. Официант является интерфейсом вашего взаимодействия с рестораном - вам не нужно знать о том как готовится еда, ингредиенты, как рассчитывать чек, все это сделает ресторан, и отдаст вам результаты при помощи официанта, который в этом примере представляет собой API ресторана. От вас скрываются сложные детали и просто происходит общение между двумя системами - клиентом и рестораном.
Вернемся к компьютерам. Предположим, что у нашей платформы доступного айти образования Merion Academy есть интерфейс работы с клиентами - тот самый API, в котором есть определенные функции, куда можно отправить какой - то запрос, и получить ответ. Представим, что у нашего API есть функция вернуть список курсов по Linux, на которые сейчас действует скидка 50% - в такой случае браузер должен сделать запрос к нашему API на получение такого списка курсов, а ответ получить эти данные и отрисовать на странице.
Важно учесть, что API интерфейсы не всемогущи - вы получите только те функции, которые заложил разработчик. Например, если помимо курсов по Linux со скидкой 50% вы захотите еще получить прогноз погоды в селе “Добрые Пчёлы” - то сорри, наш API пока так не умеет. Для добавления каждой такой новой функции программист должен разработать ее.
API состоит из двух частей: это сам интерфейс взаимодействия, скажем так некий мост, портал, окно, а вторая часть - это его описание, которое отвечает на вопрос “а как этой штукой то пользоваться?”
Взаимодействие может быть не только между клиентом и сервером, как в примере с нашей ИТ платформой, но и между серверами. Представьте: решили вы полететь в солнечный Дубай, купили билетик на сайте, а он вам еще и погоду показывает. Как же так! Неужели у компании по продаже билетов еще и метеорологические датчики по всему миру стоят, которые сообщают о погоде? Конечно нет - сайт с билетами взаимодействует с каким - то сервисом погоды по API, который как раз занимается погодными данными. А сайт с билетиками еще и скорее всего платит за каждый запрос небольшую денюжку.
Кстати, API может быть не только у веб - сервисов, где общение происходит по протоколу HTTP. API есть и у операционных систем, для взаимодействия с самой операционкой и железом. Например, если вы создаете свой аналог инстаграма, то для работы с камерой на устройстве вам нужно взаимодействовать с API системы, которая уже знает как работать с камерой, а не придумывать что-то самому с нуля, да еще и для миллиона разных устройств.
API действительно делает жизнь разработчика удобнее, а чтобы работа с API не превратилась в бардак, оно стандартизировано. Самый популярный, это конечно же REST API, но перед тем как перейти к нему, скажем пару слов про SOAP (Service Object Access Protocol), который появился несколько раньше и описывал правила синтаксиса для сообщений запросов и ответов, отправляемых веб-приложениями. Подробнее про SOAP - тут.
Ну и все, кто поддерживал SOAP должны были обмениваться XML-сообщениями между системами через HTTP или SMTP. XML (Extensible Markup Language), он же расширяемый язык разметки - это формат для хранения и передачи данных, в котором данные размещены в тегах, что делает их легко читаемыми как для компьютера, так и для человека.
Развиваясь, люди перешли на REST, который в отличии от SOAP не является протоколом, а является архитектурным стилем. В SOAP приходилось писать в разы больше кода и заворачивать каждое сообщение в XML.
REST же делает данные доступными в качестве ресурсов, которые представлены уникальным URL-адресом, и можно запросить этот ресурс, указав его URL-адрес. Например чтобы посмотреть свои подписки на ютубе нужно выполнить запрос на вот такой адрес https://www.youtube.com/feed/subscriptions.
Веб-API, соответствующие стандартам подхода REST, называются RESTful API. Они используют различные HTTP-запросы для работы с ресурсами, такие как GET - запрос, который используется для получения информации или POST, который в свою очередь нужен для отправки данных.
RESTful системы поддерживают обмен сообщениями в различных форматах, таких как самый обычный текст, HTML формат, YAML, XML и JSON, в то время как SOAP разрешает только XML, как мы и сказали ранее. Самый популярный это конечно JavaScript Object Notation, он же JSON - простой и универсальный формат, который содержит в себе набор пар ключ:значение.
Также хотим сказать про штуку, которая называется gRPC (Remote Procedure Calls) которая в основном используется для связи между разными сервисами и работает очень быстро благодаря тому что тут используется протокол HTTP/2 который работает гораздо быстрее засчет всяких новинок вроде сжатия хедеров, а вместо JSON или XML используется формат Protocol Buffers (protobuf), который работает быстрее и потребляет меньше ресурсов при работе с ним. Работает все это настолько быстро, что можно делать вызов к функции на другом сервере с такой же скоростью, как если бы она находилась на нашем. Подробнее про gRPC и Protobuf - тут
Ну и не можем не сказать про модный GraphQL - это язык запросов для API который позволяет указывать точные данные, которые ему нужны, и упрощает получение и склейку данных из нескольких источников, поэтому разработчик может использовать один вызов API для запроса всех необходимых ему данных.
