Кем бы вы ни работали в IT, познакомиться с API придется. Знание базовых принципов, по которым программы «разговаривают» друг с другом, поможет в работе не только программистам и тестировщикам, но и аналитикам и менеджерам продукта.
Рассказываем в статье, что такое API, как с ним работать и говорить на одном языке с программистами, экономить время на создании продуктов и тестировать гипотезы на раз-два.
Что такое API и зачем он нужен
API — Application Programming Interfaces — это программный интерфейс приложений. Технология соединяет разные системы и связывает программы друг с другом.
Использование API поможет гораздо меньше кодить, а вместо этого брать уже существующие данные, функции и приложения и на их основе создавать новые продукты. Скорость и экономия времени ценятся в IT.
Работа с API полезна, когда нужно быстро получить данные, сократить время разработки, адаптировать продукт к новому рынку, проверить работоспособность вашего MVP или масштабировать бизнес.
Менеджеры продуктов и аналитики должны понимать базовые понятия и как использовать API, чтобы уверенно разговаривать с командой разработки и использовать весь потенциал этого решения для быстрого создания продуктов и улучшения клиентского опыта.
А тестировщики изучают API, чтобы уметь тестировать их корректную работу. Этому учат на курсе Skypro «Инженер по тестированию». За несколько месяцев получите навыки и знания, которые необходимы новичку для начала работы. Найти подходящую вакансию помогут специалисты центра карьеры.
Хорошо спроектированная инфраструктура API экономит затраты, увеличивает доходы и создает новые бизнес-модели для компании (проверено Google, Amazon, Slack и Facebook*).
Программисты обязаны понимать устройство API и его возможные функции: даже если вы не пишете API как backend-разработчик, вы к нему обращаетесь как frontend-разработчик. В курсе «Веб-разработчик» есть блок об особенностях взаимодействия с браузерными и внешними API.
Основные виды API
API бывают внутренние и публичные, партнерские и составные.
Внутренние API используют, когда нужно связать ПО с разными сервисами внутри компании, которые создали сотрудники. Еще внутренние API помогают работе собственных приложений, например при внутренней передаче данных.
Публичные API создают для совместного использования. Кто-то делает приложение и открывает доступ, а другие разработчики могут пользоваться его функциями для своей работы и экономить время.
Например, в Slack вы можете не только отслеживать задачи и ставить потрясающие анимированные реакции на сообщения коллег, но и делать собственное приложение на его основе. Оно будет отправлять сообщения, генерировать оповещения и создавать группы на платформе. Писали не вы — а пользуетесь вы.
Есть еще партнерские API — они публичные, но с оговоркой: пользоваться ими может не кто угодно, а только авторизованные партнеры. Например, ЮMoney не даст принимать платежи онлайн, пока вы не заключите с компанией договор и не получите ключ доступа.
И есть составные — это система API, которая объединяет два или больше разных API, чтобы решить какую-то сложную задачу.
Примеры использования API
Простой, но жизненно необходимый API: сервис, который позволяет узнать всё о Покемонах — от их классификации и способностей до новых игр и фанатских сервисов.
Сложный составной API рассмотрим на примере городского транспорта: допустим, у нас есть много автобусов и трамваев и каждый передает информацию о своем местоположении в единое общее внутреннее API.
Каждая транспортная компания агрегирует свои данные, но целую картину увидит только государственная компания, которой нужно выводить на табло остановок общественного транспорта информацию о времени прибытия ближайшего автобуса. У нее свое публичное API.
Кстати, данные из него могут передаваться и дальше — например, на какие-то картографические сервисы, которым хочется предлагать эту информацию своим пользователям. Пример такого API.
Как работают API
Запросы и ответы
API работают с использованием «запросов» и «ответов». Запросы — это взаимодействие с API, а ответы — результат этого взаимодействия.
Например, технология точного прогноза погоды Meteum 2.0 получает запросы с устройств пользователей, которые боятся попасть под дождь.
Она берет информацию из пяти крупных центров, которые передают данные о погоде, дополняет их данными от пользователей, которые находятся в требуемом регионе, и выдает ответ.
В теле запроса вы сообщаете API, из какого региона хотите получить информацию о погоде. Meteum 2.0 возвращает запрошенную информацию в виде зашифрованного сообщения. Как именно будет передаваться информация и как ответ поймет система API — прописано в документации.
HTTP-методы
В запросах к наиболее популярным API (RESTFUL API) необходимо использовать HTTP-методы. Запомните всего три метода: POST, GET и PUT.
POST используют для создания новых ресурсов. Например, если бы вы хотели создать новое текстовое сообщение с помощью общедоступного API Slack, где ресурс — это сообщение.
GET используют для чтения данных. Например, в Meteum 2.0 этот метод отвечает за получение информации о погоде.
PUT используют для обновления или замены данных. Например, обновление адреса электронной почты пользователя.
Использовать эти запросы для тестирования API учат на курсе Skypro «Инженер по тестированию». В программе есть специальный блок, который этому посвящен. В результате выполните рабочий проект в Postman, пройдете нагрузочные тесты и освоите азы автоматизации тестирования.
Конечные точки — эндпоинтc (Endpoints)
Эндпоинт — это место, в котором API соединяется с программой.
Вот вы попросили Алису из «Яндекса» узнать погоду в Йошкар-Оле. Она отправила запрос к API Meteum 2.0, а он обратился к серверам прогнозистов из национальных центров России, США, Канады, Японии и ЕС, к своей внутренней системе аналитики и к пользователям, которые недавно выходили из дома и могут поделиться опытом наблюдения дождя, чтобы ответ был релевантным.
Все эти концы, «торчащие» из программы, называются Endpoints, или конечные точки.
Одна и та же конечная точка может работать с несколькими HTTP-методами — запрашивать, получать и менять данные в последовательных запросах.
Коды ответов
В процессе взаимодействия с API вы получаете разные типы сообщений — коды. Они показывают успех или неудачу запроса.
Есть куча кодов ошибок — от 001 до 1000-х, но в целом ориентироваться можно так:
- коды в диапазоне 200 указывают на успех;
- коды в диапазоне 400 указывают на ошибку на основании предоставленной информации: например, требуемый параметр не был отправлен;
- коды в диапазоне 500 указывают на ошибку на серверах API.
Подробная информация об этих сообщениях описана в документации API: обычно там, где говорится об обработке ошибок.
Аутентификация и авторизация
Большинство API-интерфейсов требуют какую-либо аутентификацию пользователя перед выполнением запроса к своим службам. Это мудро: и данные о пользователях получены, и условия безопасности соблюдены.
Аутентификация просто демонстрирует API, кто тот пользователь, который обращается к его службе. Обычно она состоит из имени, пароля и токена доступа.
Авторизация не просто собирает данные, а выдает разрешение на использование API — то есть определяет, что можно и что нельзя делать разным группам пользователей в ходе работы.
Документация API
Очень нужная штука, которую нужно уметь читать хотя бы наискосок. Благодаря документации пользователь и API могут общаться «на одном языке» и оба получают то, что хотят. В ней прописано:
- как вы докажете API, что вы — это вы;
- что можно делать через этот API;
- как передаются параметры в запросах, чтобы API понял, что от него хотят;
- как нужно отправлять эту информацию внутри сервиса;
- количество запросов, которые можно сделать за определенный период времени;
- как будет возвращаться ответ;
- какие коды ответов присутствуют и как обрабатывать возможные полученные ошибки.
Пример документации: единый API для приема платежей, отправки чеков, проведения возвратов и других операций.
Где найти новые API
Большие компании размещают новинки у себя на сайтах и рассказывают об этом в рассылках и социальных сетях. Подпишитесь на обновления любимых компаний, лидеров вашей отрасли, чтобы быть в курсе.
Еще есть открытые платформы, торговые площадки и каталоги, где любой желающий может выставить свой публичный API на продажу.
Размещение API может помочь монетизировать решения компании — и добавить узнаваемости.
А вот сайт, где собрано много API-документации.
Отслеживайте и эти подборки: Rapid API, Public API, APIList.
А на курсе Skypro «Java-разработчик» можно создать собственный API. Разберетесь, что это такое, зачем нужно и под руководством опытного наставника напишете код API, чтобы разработать веб-приложение.
Как правильно работать с API
- Подготовиться: изучить документацию, зарегистрироваться в системе партнера, если это необходимо, получить ключ.
- Вызвать API, авторизовавшись с вашим ключом.
- Отправить запрос.
- Получить ответ или код ошибки.
- Передать полученные данные в вашу систему или отобразить результат пользователю.
- Наслаждаться успехом.
Как тестировать API
В основном нужно проверять ответы сервера, выполняя запросы к адресам API для тестирования производительности.
Еще писать модульные тесты для проверки бизнес-логики и корректности функций, проверять безопасность, имитируя системные атаки.
Вот что рассказала тестировщица, которая «встретилась» с API:
«Часто API — нелюбимый ребенок у разработчика. Не каждый пишет нормальную документацию, многие умудряются обновлять версии без поддержки старых.
Если API публичный — нужно не забывать поддерживать „песочницу“ для интегрантов. Если внутренний — есть сложности в проверке обновлений бэка и фронта. Если обновился бэк — нужно сразу проверять и API, а об этом многие забывают или не придают значения».
Но при должной поддержке версионности и своевременном обновлении документации проблем не возникает.
Что почитать
Про важность API: манифест Безоса про API в Amazon — на сайте.
Еще API-примеры: как обновлять информацию о доступных вкусах своего мороженого через REST API — доступный ролик на английском.
Главное
API — это не страшно и очень функционально. Современные REST API просты: для работы с ними достаточно знания нескольких команд и знакомства с документацией.
При этом API не только дает возможность задать архитектуру продукта, но и позволяет быстро итерировать наработки со всего мира, быстрее проверять гипотезы, поскольку вы или ваши разработчики будут использовать существующую инфраструктуру.
Он формирует плацдарм для новых разнообразных продуктов на базе вашего. И наоборот — можно подглядеть и применить API-функции, которые уже кто-то создал.
*Продукты компании Meta запрещены на территории РФ.
Добавить комментарий