API: объясняю как можно проще
Постараюсь объяснить проще на примере ресторана (это оказалось сложнее, чем с Agile, хотя казалось бы...)
API (Application Programming Interface) – интерфейс общения между программами. Это как "меню" или "набор правил", который позволяет разным программам общаться между собой.
Представим, что я пришла в ресторан: сажусь за столик, и ко мне подходит официант с меню. В этом меню — чёткий список блюд, которые я могу заказать. Я выбираю стейк средней прожарки с картофелем фри и передаю заказ официанту.
Что происходит дальше? Я не вижу, как повар готовит мой стейк, не знаю, где он берёт мясо и как его маринует. Мне важно только, чтобы официант принёс мне мой заказ как можно скорее. Если я передумаю и захочу изменить прожарку на medium rare или убрать гарнир — официант передаст эту просьбу на кухню, и мне принесут обновлённый заказ.
Я не вмешиваюсь в работу кухни и не говорю, как ему готовить — повар сам знает, что делать.
Точно так же происходит запрос через API: когда одна программа хочет взаимодействовать с другой, она не лезет во внутренние процессы, а просто делает "заказ".
Получается, что:
Официант - это API. Он принимает заказ и возвращает его с кухни.
Меню - это документация и правила API. В документации API прописаны все возможные варианты, которые API может вернуть, и дополнительные параметры.
Кухня - сервер, который обрабатывает наш запрос и возвращает ответ через API. Он сам знает, что нужно сделать, чтобы ответить нам; нам нужно только принять информацию и обработать её.
Самый распространённый вид API — REST API.
Он работает через HTTP-запросы (про HTTP то я и напишу в следующий раз).
Например, в ресторане мы можем не только заказать еду, но и попросить изменить или отменить заказ. В REST API тоже есть разные запросы:
GET — посмотреть меню: "Какие у вас есть стейки?"
В цифровом мире: получение списка товаров, статей или любой другой информации
POST — сделать новый заказ: "Я буду стейк medium well с картофелем фри"
В приложении: создание нового заказа, регистрация пользователя
PATCH — изменить часть заказа: "Можно поменять прожарку на medium rare?"
В личном кабинете: изменить телефон или адрес доставки. Получается, что PATCH — это частичное изменение ресурса.
PUT — полностью переделать заказ: "Вместо стейка я возьму пасту карбонара"
В корзине интернет-магазина: заменить все выбранные товары. То есть PUT — это полная замена ресурса.
DELETE — отменить заказ: "Я передумал, отменяйте мой заказ"
Удаление товара из корзины или отмена подписки
Зачем это нужно не только программистам?
Понимание API помогает:
- Оценить, сколько времени займёт подключение к другому сервису
- Понимать, почему нельзя просто "быстро добавить" какую-то функцию
- Грамотно ставить задачи разработчикам, зная основные возможности и ограничения
- Не растеряться на собеседовании, даже если вы понимаете, как работает API, но объяснить не можете)
Конечно, все эти примеры с ресторанами, официантами и кухнями — утрированные. В реальной разработке всё сложнее: есть авторизация, токены, кэширование, ошибки API (например, 403 и 404) и множество других нюансов, о которых я постараюсь написать попроще. Но если вы — руководитель, менеджер, аналитик или другой специалист, который только начинает разбираться в IT, такие аналогии помогут уловить суть: без API современным сервисам было бы сложнее работать вместе:)
Я начала вести тг канал, где рассказываю просто о сложном в IT. Если вы дочитали этот пост, то скорее всего вас интересует тема, поэтому буду рада, если поддержите подпиской: https://t.me/jer_it