Когда вы смотрите погоду на телефоне, оплачиваете заказ картой или входите на сайт через кнопку «Войти через Яндекс», за кулисами одна программа тихо спрашивает другую: «Дай мне данные», и получает ответ за доли секунды. Этот обмен идёт через API. Слово звучит технически, но за ним прячется простая идея: договорённость, по которой программы общаются друг с другом.
API (application programming interface, программный интерфейс приложения) — это набор правил, через которые одна программа запрашивает данные или действие у другой. Здесь кнопки ни при чём: с одним кодом общается другой код. В этой статье разберём по порядку: что такое API и зачем он нужен, как устроена связка «клиент — сервер», что такое эндпоинт, чем отличаются методы GET и POST, что такое REST API и в каком виде приходит ответ.
Ответ от API чаще всего приходит в формате JSON, и если это слово вам ни о чём не говорит, начните с соседнего разбора: что такое JSON простыми словами. Эти две темы идут в паре: API передаёт данные, JSON — тот «язык», на котором они записаны.
Статья пригодится не только будущим программистам. Про API спрашивают маркетологи, аналитики, менеджеры проектов, все, кто хоть раз слышал «а это можно подтянуть по API?» и не понял, о чём речь. А делают эти интерфейсы обычно бэкенд-разработчики. Если интересно, кто именно и чем занимается, посмотрите обзор как стать backend-разработчиком.
Если после статьи захочется не просто понять, а научиться делать такие вещи руками, у нас собрана подборка курсов по веб-разработке, от коротких вводных до годовых программ с трудоустройством. Но это в конце, а пока разберёмся с самим понятием.
КурсыСравнение 162 курсов по веб-разработкеЦены, школы, длительность, рассрочка
Что такое API и зачем он нужен
Представьте ресторан. Вы сидите за столиком и хотите пасту. На кухню вы не идёте: там свои правила, чужому туда нельзя. Вместо этого приходит официант, вы называете блюдо из меню, официант передаёт заказ повару и приносит готовую тарелку. Вам не нужно знать, как устроена плита и где лежат продукты. Достаточно меню и официанта.
API — это официант. Вы (одна программа) делаете заказ, кухня (другая программа или сервер) его готовит, а API ходит между вами и передаёт запрос туда, а результат обратно. Меню в этой аналогии — список того, что вообще можно попросить. Каждый пункт меню — это отдельная операция, которую API умеет выполнять.
Зачем такая прослойка? Чтобы программы не лезли друг другу во внутренности. Погодному приложению на вашем телефоне не нужно знать, как метеосервис хранит миллионы замеров температуры. Оно просто спрашивает: «Какая погода в Москве сейчас?», и получает готовый ответ. Всё остальное — забота сервера.
Коротко. API нужен, чтобы одна программа могла попросить у другой данные или действие, не разбираясь в том, как та устроена внутри. Меню известно обеим сторонам, а кухня остаётся закрытой.
Из этого следует важная мысль: API — это договорённость, а не программа. Это согласованный заранее список: какие запросы можно присылать, в каком виде и что придёт в ответ. Обе стороны держатся правил, поэтому обмен идёт предсказуемо. Стоит одной стороне сломать правила, и официант перестанет понимать заказы.
Клиент и сервер: кто кого спрашивает
Почти любой обмен через API держится на двух ролях. Их называют клиент и сервер, и эти слова стоит запомнить, потому что дальше они встретятся много раз.
Клиент — тот, кто спрашивает. Это приложение на вашем телефоне, сайт в браузере, программа на компьютере. Клиент формирует запрос: «дай погоду», «покажи баланс», «сохрани заказ».
Сервер — тот, кто отвечает. Это удалённый компьютер, где хранятся данные и работает нужная логика. Сервер принимает запрос, обрабатывает его и отправляет результат обратно клиенту.
В нашей аналогии посетитель за столиком — клиент, кухня — сервер, официант — API между ними. Клиент никогда не ходит на кухню напрямую, и это даже удобно: пока правила заказа не меняются, кухня может переставить плиты, нанять новых поваров или переехать в другое здание, а посетитель этого даже не заметит.
Тот же принцип работает в интернете. Клиент и сервер могут находиться на разных концах планеты, а общаться по единым правилам. Эти правила задаёт протокол HTTP, тот самый, что стоит в начале любого веб-адреса (http и https). Именно по HTTP клиент шлёт запрос, а сервер возвращает ответ.
Что такое эндпоинт
Вернёмся к меню. В меню несколько блюд, у каждого своё название и своё место в списке. В API роль такого пункта играет эндпоинт (endpoint, конечная точка) — адрес, по которому клиент обращается за конкретной операцией.
Эндпоинт выглядит как обычная ссылка. Например, у воображаемого погодного сервиса это может быть:
https://api.pogoda.ru/v1/weather?city=moscow
Разберём по частям. https://api.pogoda.ru — адрес самого сервера, куда стучимся. /v1/weather — путь до нужной операции, здесь «отдать погоду». ?city=moscow — параметр запроса, уточнение «для города Москва». Поменяли город в параметре, получили погоду в другом месте, а эндпоинт остался тем же.
У одного API таких эндпоинтов обычно много: один отдаёт погоду, другой — прогноз на неделю, третий — список городов. Каждый эндпоинт делает одну понятную вещь. Это и есть меню целиком: список адресов, по которым можно что-то попросить.
Запомните разницу. Сервер — это ресторан целиком. Эндпоинт — конкретный пункт меню внутри него. К одному серверу ведёт много эндпоинтов, и у каждого своя задача.
Ваня Буявец, основатель CheckroiПоказываю, как применять Claude Code, ChatGPT и другие нейросети в учёбе и работе, с примерами и промптамиЧитать в ТелеграмеHTTP-методы простыми словами: GET, POST, PUT, PATCH, DELETE
Одного адреса мало: нужно ещё сказать, что именно с ним сделать — посмотреть, добавить, изменить или удалить. Для этого к каждому запросу прикрепляют HTTP-метод, короткое слово-команду. Основных пять, и они читаются почти по-человечески.
GET — «покажи». Самый частый метод. Клиент просит данные и ничего не меняет на сервере. Открыли погоду, посмотрели ленту, загрузили список товаров — это всё GET. Его можно повторять сколько угодно раз, ничего не сломается.
POST — «создай». Клиент отправляет новые данные, и сервер что-то создаёт: регистрирует пользователя, оформляет заказ, публикует комментарий. В отличие от GET, POST несёт с собой тело запроса: например, логин и пароль при регистрации.
PUT — «измени». Клиент обновляет то, что уже есть: меняет адрес доставки, редактирует профиль, правит текст. Данные существуют, мы их переписываем.
PATCH — «поправь часть». Почти как PUT, но аккуратнее: PUT переписывает запись целиком, а PATCH меняет только одно нужное поле. Сменить email в профиле проще через PATCH, остальные данные останутся как были.
DELETE — «удали». Название говорит само за себя: убрать товар из корзины, удалить пост, стереть аккаунт.
Методов на самом деле чуть больше. Например, HEAD работает как GET, но возвращает только «шапку» ответа без самих данных, чтобы быстро проверить, есть ли что-то по адресу. А OPTIONS спрашивает у сервера, какие операции он вообще разрешает. Есть и совсем редкие служебные методы, но новичку они не понадобятся: в реальной работе почти всё крутится вокруг пяти команд выше, а HEAD и OPTIONS браузер обычно шлёт сам на фоне.
Если запутались, держите простую подсказку. Читаете что-то — это GET, всё остальное меняет данные, и тут уже смотрят на смысл: добавляем — POST, меняем целиком — PUT, правим часть — PATCH, удаляем — DELETE. Девять из десяти запросов, которые вы как обычный пользователь запускаете каждый день, — это тихие GET-запросы на фоне.
КурсыСравнение 160 курсов для программистовЦены, школы, длительность, рассрочка
Что такое REST API — самый частый вид
Когда говорят «сделай API» или «есть ли у сервиса API», почти всегда имеют в виду REST API. Это самый распространённый способ строить обмен между программами в вебе, и именно его вы встретите в 99 % случаев. Разберём, что стоит за тремя буквами.
REST (Representational State Transfer, «передача состояния представления») — не программа и не протокол. Это набор рекомендаций, как разумно устроить API. Придумал их учёный Рой Филдинг ещё в 2000 году, и с тех пор подход стал негласным стандартом. API, построенный по этим рекомендациям, называют RESTful.
Главных идей у REST несколько, и все они про порядок и предсказуемость.
Всё — это ресурс. Пользователь, заказ, товар, город с погодой: каждая сущность имеет свой адрес-эндпоинт. Хочешь работать с заказами, идёшь на /orders, с пользователями — на /users. Адреса читаются глазами и говорят сами за себя.
Действие задаёт метод, не адрес. Не нужно выдумывать эндпоинты вроде /getUser и /deleteUser. Адрес один, /users/42, а что с ним делать, решает метод: GET посмотрит пользователя, PUT изменит, DELETE удалит. Аккуратно и понятно.
Сервер не запоминает клиента. Каждый запрос самодостаточен: в нём есть всё нужное, чтобы сервер понял, чего от него хотят. Сервер не держит в голове, что вы просили минуту назад. Это упрощает жизнь и позволяет обслуживать миллионы запросов, не путаясь в них.
Если совсем просто. REST — это договорённость называть вещи понятными адресами и командовать ими понятными методами. Не магия, просто хорошие манеры, на которых сошлась почти вся индустрия.
Есть и другие подходы: SOAP, GraphQL, gRPC, но новичку про них можно не думать. Начинайте с REST: он проще всех, встречается чаще всех, и почти любой публичный сервис отдаёт данные именно так.
Что приходит в ответе: статус-код и тело
Мы отправили запрос. Что вернётся? Ответ от сервера всегда состоит из двух частей: статус-код и тело ответа.
Статус-код — трёхзначное число, которое одним взглядом говорит, как прошёл запрос. Их придумали, чтобы не читать длинных объяснений: увидел число, понял результат. Вот те, что встречаются чаще всего:
- 200 — всё хорошо, данные отдал. Самый желанный ответ.
- 201 — создано (обычно приходит в ответ на POST, когда что-то добавили).
- 404 — не найдено. Тот самый «404», который вы видели на страницах сайтов.
- 401 — не авторизован, нужен ключ или вход.
- 500 — ошибка на стороне сервера, что-то сломалось у них, а не у вас.
Число из группы 2xx — успех, 4xx — вы что-то сделали не так (не тот адрес, забыли ключ), 5xx — проблема у сервера. Этой грубой прикидки хватает, чтобы понять, кто виноват.
Тело ответа — сами данные, ради которых всё затевалось. И вот здесь появляется JSON. В подавляющем большинстве современных API тело ответа приходит именно в формате JSON, компактном текстовом виде, который одинаково понятен и человеку, и программе. Погодный сервис вернёт что-то вроде:
{ "city": "Москва", "temp": 17, "condition": "облачно" }
Клиент получает этот текст, разбирает его и показывает вам «Москва, +17, облачно». Почему именно JSON и как он устроен внутри, подробно в разборе что такое JSON. Для нашей темы достаточно запомнить: API передаёт данные, а JSON — формат, в котором они записаны. Одно без другого в вебе почти не встречается.
Сквозной пример: как запрос проходит весь путь
Соберём всё, что разобрали, в одну живую сцену. Допустим, вы открыли на телефоне приложение погоды и хотите узнать, тепло ли сейчас в Москве. Вот что происходит за те полсекунды, пока крутится значок загрузки.
Шаг 1. Клиент формирует запрос. Приложение (клиент) собирает обращение к эндпоинту метеосервиса методом GET: GET https://api.pogoda.ru/v1/weather?city=moscow. По-человечески это звучит как «покажи погоду для Москвы».
Шаг 2. Запрос уходит на сервер. По протоколу HTTP обращение летит через интернет на сервер метеосервиса. Официант понёс заказ на кухню.
Шаг 3. Сервер обрабатывает. Сервер видит: метод GET, эндпоинт weather, город Москва. Лезет в свою базу, достаёт свежие данные, готовит ответ.
Шаг 4. Сервер возвращает ответ. Обратно приходит статус-код 200 (всё хорошо) и тело в формате JSON: { "city": "Москва", "temp": 17, "condition": "облачно" }. Официант принёс тарелку.
Шаг 5. Клиент показывает результат. Приложение разбирает JSON и рисует на экране «Москва, +17, облачно». Вы видите погоду и даже не догадываетесь, что только что произошёл разговор двух программ.
Вот и весь путь: эндпоинт → метод → запрос → ответ в JSON. Любое обращение к API, каким бы сложным ни был сервис, в основе повторяет эти пять шагов. Поняли одну сцену, поняли принцип целиком.
Канал основателя Checkroi Вани БуявцаПоказываю тебе, как публично строю Checkroi с нейросетями и делюсь цифрами, провалами и тем, что сработалоПодписатьсяГде API встречается в обычной жизни
Кажется, что API — тема для программистов, но вы пользуетесь им десятки раз в день, просто не замечаете. Вот привычные ситуации, за которыми стоит тихий обмен через API.
Погода в телефоне. Приложение не хранит температуру само: оно запрашивает её у метеосервиса по API, ровно как в нашем примере.
Оплата картой. Когда вы платите на сайте, магазин не трогает ваши деньги напрямую. Он через API передаёт запрос платёжной системе, а та возвращает «оплата прошла» или «отказ». Данные карты остаются у банка, магазин их не видит.
Карты и маршруты. Приложение доставки не рисует карту с нуля: оно берёт её через API картографического сервиса и поверх показывает, где едет курьер.
Вход через Яндекс или VK. Кнопка «Войти через Яндекс» — это тоже API. Сайт спрашивает у Яндекса: «Это точно тот человек?», и Яндекс отвечает, не раскрывая ваш пароль. Поэтому не приходится заводить новый логин на каждом сервисе.
Вывод. API — это невидимый клей интернета. Почти любое приложение внутри собрано из чужих данных и сервисов, которые оно берёт по API, вместо того чтобы делать всё самому.
КурсыСравнение 452 курсов по pythonЦены, школы, длительность, рассрочка
Конкретные примеры API, которые можно потрогать
До сих пор мы говорили про API как про общее понятие. Но у него есть вполне осязаемые представители: публичные API, к которым может подключиться любой разработчик, получив ключ доступа.
Свежий пример, о котором все говорят: API нейросетей. У ChatGPT есть свой интерфейс, через который приложения отправляют текст и получают ответ модели; мы разбирали его отдельно в статье про OpenAI API. Точно так же устроен доступ к Claude. Если интересно, посмотрите разбор Claude API для начинающих или общий обзор, что такое Claude.
Важно не запутаться. Claude и ChatGPT — это конкретные продукты, а API — общий принцип, по которому к ним подключаются. Логика везде одна и та же: клиент шлёт запрос на эндпоинт с ключом доступа, сервер возвращает ответ в JSON. Разберётесь с одним API, остальные пойдут легче, потому что под капотом всё те же эндпоинты, методы и статус-коды.
Ключ доступа, о котором зашла речь, — это как именной пропуск. Многие API требуют его, чтобы понимать, кто делает запрос, и считать лимиты. Ключ добавляют к каждому запросу, и по нему сервер узнаёт клиента. Терять его нельзя: тот, у кого ключ, может слать запросы от вашего имени.
С чего начать, если хочется разобраться глубже
Если статья зажгла интерес и хочется не только понимать, но и делать, дальше дорога простая. Сначала вручную поотправляйте запросы к любому открытому API через браузер или бесплатную программу вроде Postman, чтобы своими глазами увидеть запрос и ответ. Потом научитесь дёргать API из кода: этому учат на первых же занятиях по веб-разработке и Python.
Чтобы не собирать знания по обрывкам туториалов, проще один раз пройти системный курс, где API разбирают на реальных проектах. Мы собрали и сравнили программы по направлениям, от веб-разработки до Python, где работа с API идёт с первых недель.
| Курс | Школа | Стоимость со скидкой | В рассрочку | Длительность | Обзор курса от Checkroi |
|---|---|---|---|---|---|
| Fullstack-разработчик на Python Перейти на сайт курса |  Нетология | 175 800 ₽ | 7125 ₽/мес. | 21 месяц | Обзор курса |
| Профессия «Веб-разработчик с нуля» Перейти на сайт курса | Нетология | 163 300 ₽ | 7125 ₽/мес. | 13 месяцев | Обзор курса |
| Веб-разработчик Перейти на сайт курса |  Академия Синергия | 141 036 ₽ | 5877 ₽/мес. | 6 месяцев | Обзор курса |
| Веб-разработчик Перейти на сайт курса |  Skillbox | 153 348 ₽ | 4486 ₽/мес. | 16 месяцев | Обзор курса |
| FullStack-разработчик: тариф PRO Перейти на сайт курса |  Эдюсон | 182 000 ₽ | 7583 ₽/мес. | 14 месяцев | Обзор курса |
| Fullstack-разработчик на JavaScript Перейти на сайт курса | Эдюсон | 158 760 ₽ | 6615 ₽/мес. | 11 месяцев | Обзор курса |
| Веб-разработка для фриланса Перейти на сайт курса |  Skypro | 118 320 ₽ | 364 833 ₽/мес. | 12 месяцев | Обзор курса |
| Фулстек-разработчик на JavaScript Перейти на сайт курса | Skillbox | 153 348 ₽ | 4296 ₽/мес. | 11 месяцев | Обзор курса |
| FullStack-разработчик: тариф Базовый Перейти на сайт курса | Эдюсон | 158 760 ₽ | 6615 ₽/мес. | 12 месяцев | Обзор курса |
| Веб-разработчик (c индивидуальным сопровождением) Перейти на сайт курса | Skypro | 204 000 ₽ | 368 333 ₽/мес. | 12 месяцев | Обзор курса |
Больше программ — в полном каталоге курсов по веб-разработке
А если пока хочется просто уложить в голове базовые понятия современного веба, по соседству лежат разборы что такое JSON и обзор профессии backend-разработчика, того самого человека, который эти API и создаёт.
