Интеграция через API. Кратко
API (Application Programming Interface) — это набор способов и правил, по которым можно выполнять определённые действия с системой (например, получить данные или выполнить с ними какое-либо действие). Такой набор правил называют контрактом. Система как бы говорит: «ко мне можно обращаться так и так, я обязуюсь делать то и это».
Если систему рассматривать как чёрный ящик, то API — это набор «ручек», которые доступны пользователю данного ящика и которые он может вертеть и переключать.
Подходы к проектированию API
➖ Contract First означает, что сначала определяется контракт API, а потом пишется код, который его реализует. Преимуществом этого подхода является то, что контракт API является документацией для разработчиков и потребителей API, а также может быть использован для автоматической генерации кода, тестов и клиентских библиотек.
➖ Code First означает, что сначала пишется код, который реализует логику API, а потом из него извлекается контракт API. Преимуществом этого подхода является то, что код является единственным источником правды для API, а также может быть легко изменен и расширен.
Интеграцию через API стоит использовать в тех случаях, когда:
👉 Нужно обмениваться данными или выполнять действия с другой системой в реальном времени. API позволяет отправлять и получать запросы и ответы по сети с минимальной задержкой и максимальной актуальностью данных.
👉 Нужно иметь гибкий и независимый способ доступа к функциональности системы. API позволяет выбирать нужные данные и действия из всего набора возможностей системы, а также не зависит от внутренней реализации и технологии системы.
👉 Нужны безопасность и контроль доступа к системе. API позволяет использовать различные механизмы аутентификации и авторизации для защиты данных и доступа к системе от несанкционированного или злоупотребительского использования.
Однако интеграция через API также имеет некоторые недостатки:
🔻Сложность. API требует знания спецификации контракта и формата данных для каждой конечной точки. Также необходимо учитывать ошибки, исключения и ограничения при работе с API.
🔻Нестабильность. API может изменяться со временем, что может привести к несовместимости или поломке интеграции. Поэтому важно следить за версионированием и обратной совместимостью API.
🔻Зависимость. API может быть недоступен или работать медленно из-за сетевых проблем или перегрузки системы. Поэтому необходимо иметь стратегию обработки сбоев и отказов API.
Какие бывают API:
🌟 SOAP: часто используется в корпоративных системах. Например, он может быть встроен в старые версии CRM-систем или в банковских приложениях.
🌟 REST: очень популярен в современных веб-приложениях. Под этот тип API, например, работают большинство публичных API таких сервисов как Twitter, GitHub или Stripe.
🌟 GraphQL: используется, когда требуется гибкость в выборе данных для запроса и по одному эндпоину (URL) можно получить разные варианты ответов.
🌟 WebSocket: применяется, когда необходимо поддерживать постоянное соединение между клиентом и сервером. Так, он может быть использован в чатах или онлайн-играх.
🌟 gRPC: разработанный Google для высокопроизводительных приложений, он может быть встроен, например, в облачных решениях или микросервисах.
Другие способы интеграции описаны здесь. В следующих постах разберём REST.
📎 Материалы по теме
1. Что такое API? — статья от Amazon
2. Что такое API — статья от Doka
📖 Книги
1. Сергей Константинов. API
2. Арно Лоре. Проектирование веб-API
3. Web API Design: The Missing Link — небольшая книга от Google о проектировании API в REST стиле
▶️ Видео
1. Что такое API — Merion Academy
2. API для начинающих. Пример VK — Marlin
3. Как аналитику спроектировать свой REST API // Демо-занятие курса «Специализация «Системный аналитик»
4. API: под каким углом на них смотреть — доклад c конференции Analyst Days от Мелеховой Анны, Лаборатория Касперского
👍 Примеры открытых API
1. API ВКонтакте — можно потыкать ручками через веб-интерфейс
2. API DaData
3. Пример API Swagger
#api #интеграции
API (Application Programming Interface) — это набор способов и правил, по которым можно выполнять определённые действия с системой (например, получить данные или выполнить с ними какое-либо действие). Такой набор правил называют контрактом. Система как бы говорит: «ко мне можно обращаться так и так, я обязуюсь делать то и это».
Если систему рассматривать как чёрный ящик, то API — это набор «ручек», которые доступны пользователю данного ящика и которые он может вертеть и переключать.
Подходы к проектированию API
➖ Contract First означает, что сначала определяется контракт API, а потом пишется код, который его реализует. Преимуществом этого подхода является то, что контракт API является документацией для разработчиков и потребителей API, а также может быть использован для автоматической генерации кода, тестов и клиентских библиотек.
➖ Code First означает, что сначала пишется код, который реализует логику API, а потом из него извлекается контракт API. Преимуществом этого подхода является то, что код является единственным источником правды для API, а также может быть легко изменен и расширен.
Интеграцию через API стоит использовать в тех случаях, когда:
👉 Нужно обмениваться данными или выполнять действия с другой системой в реальном времени. API позволяет отправлять и получать запросы и ответы по сети с минимальной задержкой и максимальной актуальностью данных.
👉 Нужно иметь гибкий и независимый способ доступа к функциональности системы. API позволяет выбирать нужные данные и действия из всего набора возможностей системы, а также не зависит от внутренней реализации и технологии системы.
👉 Нужны безопасность и контроль доступа к системе. API позволяет использовать различные механизмы аутентификации и авторизации для защиты данных и доступа к системе от несанкционированного или злоупотребительского использования.
Однако интеграция через API также имеет некоторые недостатки:
🔻Сложность. API требует знания спецификации контракта и формата данных для каждой конечной точки. Также необходимо учитывать ошибки, исключения и ограничения при работе с API.
🔻Нестабильность. API может изменяться со временем, что может привести к несовместимости или поломке интеграции. Поэтому важно следить за версионированием и обратной совместимостью API.
🔻Зависимость. API может быть недоступен или работать медленно из-за сетевых проблем или перегрузки системы. Поэтому необходимо иметь стратегию обработки сбоев и отказов API.
Какие бывают API:
🌟 SOAP: часто используется в корпоративных системах. Например, он может быть встроен в старые версии CRM-систем или в банковских приложениях.
🌟 REST: очень популярен в современных веб-приложениях. Под этот тип API, например, работают большинство публичных API таких сервисов как Twitter, GitHub или Stripe.
🌟 GraphQL: используется, когда требуется гибкость в выборе данных для запроса и по одному эндпоину (URL) можно получить разные варианты ответов.
🌟 WebSocket: применяется, когда необходимо поддерживать постоянное соединение между клиентом и сервером. Так, он может быть использован в чатах или онлайн-играх.
🌟 gRPC: разработанный Google для высокопроизводительных приложений, он может быть встроен, например, в облачных решениях или микросервисах.
Другие способы интеграции описаны здесь. В следующих постах разберём REST.
📎 Материалы по теме
1. Что такое API? — статья от Amazon
2. Что такое API — статья от Doka
📖 Книги
1. Сергей Константинов. API
2. Арно Лоре. Проектирование веб-API
3. Web API Design: The Missing Link — небольшая книга от Google о проектировании API в REST стиле
▶️ Видео
1. Что такое API — Merion Academy
2. API для начинающих. Пример VK — Marlin
3. Как аналитику спроектировать свой REST API // Демо-занятие курса «Специализация «Системный аналитик»
4. API: под каким углом на них смотреть — доклад c конференции Analyst Days от Мелеховой Анны, Лаборатория Касперского
👍 Примеры открытых API
1. API ВКонтакте — можно потыкать ручками через веб-интерфейс
2. API DaData
3. Пример API Swagger
#api #интеграции