API — это способ попросить систему выполнить за нас работу. Мы даем что-то на входе (input) и получаем ответ (output) на выходе. При этом нам совершенно все равно, что именно система делает для получения результатов — в этом вся суть.

Например, заказывая кофе, мы обмениваем деньги и выбор (input) на чашку кофе (выход). Нам вообще неважно, как этот кофе был доставлен из сортировочного центра и на какой полке хранился на складе. Все, что нам здесь интересно — это качество результата в нашей чашке.

Представим, что вы — продакт приложения для бегунов и хотите интегрировать прогноз погоды в приложение (не всем нравится бегать под дождем). Вы немного погуглили и нашли этот документ (платного) API погоды:

Что мы здесь сразу видим? Вы можете передать город (он у вас есть!), дату/время (они тоже есть) и получить температуру в градусах Цельсия, а также погодные условия. А еще:

• У пользователей будут проблемы в пригородах подальше от городов (поскольку API не поддерживает простые координаты, а только города).
• Температура указана только в градусах Цельсия (пострадают клиенты из США и прочих стран, где используют Фаренгейты). Поэтому надо будет добавить свой простой "переводчик" между температурами.
• Ничего не говорится о ветре (бегунам может быть некомфортно, если ветер будет сильнее определенного порога).

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

Предположим, что мы хотим добавить в наше беговое приложение новую крутую фичу — маршруты для бегунов. Да, Google может построить маршрут для водителей и пешеходов, но бегунам нужно немного другое. Мы предполагаем, что пользователь может указать параметры тренировки и получить идеальный маршрут для пробежки. Запрашиваем у бэкенд команды следующий API:

Заметьте, как мы перешли от невнятного «маршрут для бегунов» к более конкретному соглашению по input / output. Это уже можно обсуждать с технической командой: смогут ли они это построить, чего не хватает и т.д.
Мы не упоминаем, как это будет реализовано: хитрым ML-ем или с помощью какого-то простого набора правил. Но мы четко говорим, что пользователи будут отправлять и что мы ожидаем в ответ — это хорошее ограничение для того, чтобы начать работу.

Продакт должен помнить следующее:

• API состоит из input & output (включая возможные ошибки).
• Продакт должен сосредоточиться на основной ценности продукта, а в остальном использовать API для аутсорсинга работы. Необходимую функциональность можно быстро найти и прочитать документацию. С высокой вероятностью умные разработчики уже создали логику, которая вам нужна.
• Если нужно выдать требования для других сервисов, вы можете сделать это в форме API input/output. Это применимо, если вы хотите предложить (или продать) часть своего функционала через API.

Хотите попробовать вызвать API своими руками? В реальности это проще, чем кажется. Вот ссылка на тренажер - без регистрации и СМС.

Хотите прокачать технические навыки в целом? Приходите на симулятор "Технологии для продакта", там мы разбираем такие важнейшие темы, как API, архитектура (Service Diagram), оценку сложности проектов, SLI/SLOs, и так далее.