Ситуация и пример;Шаги продакта;Пример шагов;Научиться
<b style="color:white">Нужна новая функциональность, которая уже доступна по API внутри или вне компании</b><br>Нужно подключить возможность переключить валюту и перевести в нее цену;1) Ищем документацию (внутри компании или в интернете)<br><br> 2) Читаем описание (description) API эндпоинта, который лучше всего подходит под требования<br><br>3) Понимаем входные параметры (то, что нам нужно будет откуда-то достать в нашем продукте и отправить в API)<br><br>4) Понимаем выходные параметры (то, что мы получим от API и используем в продукте)<br><br>5) Понимаем возможные ошибки (чтобы подготовить продукт к тому, что в ответе не всегда будет успех)<br><br>6) Есть ли у API какие-то особенности? (например, является ли API асинхронным)<br><br>7) Отлично, можно писать задание команде интеграцию: что/зачем подключить, какие параметры отравлять и какие принимать.;1) Нашли https://openexchangerates.org/<br><br>2) Нашли эндпоинт /convert<br><br>3) Увидели, что надо передать текущую цену, текущую валюту и целевую валюту<br><br>4) Обратно получим сконвертированное значение цены<br><br>5) Если передать неверный код валют, то API вернет ошибку.<br><br>6) Особенностей нет, очень простой API.<br><br>7) Упрощенная версия: “Нужен обмен валют между RUB, EUR, USD. Вот API - доступ уже оплачен. Надо передать туда текущую цену корзины и выбранную пользователем валюты и полученную конвертированную величину вернуть на UI для отображения. В случае ошибки вернуть “Конвертация не получилась, попробуйте позже.”;Три практических примера на работу с доками в симуляторе "Тех для продакта" link=https://productdo.it/tech_pm;
<b style="color:white">Хочу понять, какие главные API нашего продукта?</b><br>Устроился в новую команду и пытаюсь разобраться;1) Просим Engineering Manager или тех лида описать все API, которые мы выставляем клиентам <br><br>2) Просим его же описать, что эти клиенты с ответами нашего API делают;1) У нас сервис отзывов, поэтому наши самые главные API это:<br><b>/submit_review</b>(ride_id, rating, text_review) → “OK” or “Error”<br><br><b>/get_all_reviews(driver, period)</b> → List of {date, ride, text, rating}<br><br>2) Нас вызывает главное приложение, чтобы передать отзыв, а также страница водителя, чтобы получить список всех отзывов;Два кейса на создание своего API в симуляторе "Тех для продакта" link=https://productdo.it/tech_pm;
<b style="color:white">Хочу понять, от каких других сервисов/API мы зависим</b><br>Устроился в новую команду и пытаюсь разобраться;1) Просим Engineering Manager или тех лида описать все API, от которых мы зависим.<br><br>2) Задаем вопрос: стабильны ли эти зависимости, были ли нарушения SLO?;1) Мы зависим от API нотификаций, которые используем, чтобы напомнить пользователю оставить отзыв.<br><br>2) В прошлом месяце API ломалось трижды и “пробило” SLO 99.9% (факт: 93.1%) - надо идти и ругаться с продактом данного API.;Три практических примера на оценку API зависимостей и SLI/SLO в симуляторе "Тех для продакта" link=https://productdo.it/tech_pm;
<b style="color:white">Клиент требует создать новую функциональность по API</b><br>Просят возвращать примерное время доставки заказанной еды;1) Встречаюсь с клиентом, понимаю требования, что и зачем он хочет, какие юз-кейсы, какие данные у него есть и что он хочет получить обратно<br><br>2) Предлагаю "контракт" API: входные параметры, выходные параметры, возможные ошибки.<br><br>3) Если мы договорились, то выкатываю данное API в тестовом режиме (программисты знают, что это).<br><br>4) Пишу понятную документацию: описание API и каждого параметра и ошибок.<br><br>5) Добавляем API мониторинг (Service Level Indicators) и договариваемся о Service Level Objectives.<br><br>6) Выкатываем API в полноценный продакшн.;1) Команда UI хочет показывать примерное время доставки еды заказавшему.<br><br>2) Предлагаю, что они передают мне ресторан и адрес покупателя, а я рассчитываю и возвращаю временную оценку (например, среднее время готовки в этом ресторане + время на доставку).<br><br>3) Договорились, через спринт выкатили API в “песочнице”.<br><br>4) Сделал понятные доки.<br><br>5) Определили SLI: reliability и latency, поставили для них SLO 99.9%<br><br>6) Выкатили, API доступно по /foodorder/v1/delivery_time.;Два кейса на создание своего API в симуляторе "Тех для продакта" link=https://productdo.it/tech_pm;
<b style="color:white">Хочется самому попробовать API</b><br>Команда говорит “API готово” - хочу сам проверить, могу я с ним поиграться?;1) Если это GET-endpoint, можно просто через браузер (см. пример справа).<br><br>2) Если это GET или POST endpoint, можно вызвать через инструмент Postman.;1) Вот вызов Meme API: https://apimeme.com/meme?meme=Spiderman-Computer-Desktop_Even_Spiderman_studies_at_ProductDo (см. диаграмму выше).<br><br>2) Пример с Postman сложнее чуть сложнее в настройке, см. курс “Технологии для продакта”.;Три кейса на вызов API Такси в симуляторе "Тех для продакта" link=https://productdo.it/tech_pm;
<b style="color:white">Мне попалась сложная API интеграция</b><br>Несколько сервисов вызывают друг друга один за другим.;1) Строим Sequence Diagram, и нам будут сразу видны все зависимости.<br><br>2) Отображаем на диаграмме все особенности, например, что делать, если ответ возвращается асинхронно? А что делать, если данный вызов вернет ошибку: останавливать всю цепочку вызовов или пробовать еще раз?;1) Задание по Sequence Diagram для вызова API Telegram см. в курсе;Кейс на Sequence DIagram в симуляторе "Тех для продакта" link=https://productdo.it/tech_pm;
