Как ответить
API (Application Programming Interface) в клиент-серверном взаимодействии — это чётко описанный контракт: набор правил, по которым программа-клиент отправляет запросы на сервер, а сервер присылает ответ. Без API клиент не знает, как и о чём просить, а сервер — как отвечать, чтобы клиент понял.
Чаще всего API строится поверх HTTP. Клиент отправляет HTTP-запрос на определённый endpoint (URL) с методом (GET, POST, PUT, DELETE), передаёт данные — в теле запроса (body) или в параметрах строки URL. Сервер обрабатывает и возвращает HTTP-ответ с статус-кодом (200 OK, 201 Created, 404 Not Found, 500 Internal Server Error) и телом, обычно в JSON.
Простой пример — получение списка пользователей. Клиент делает GET-запрос на /api/users. Сервер может ответить:
HTTP/1.1 200 OK
Content-Type: application/json
{
"users": [
{"id": 1, "name": "Анна"},
{"id": 2, "name": "Пётр"}
]
}Клиент парсит JSON и выводит список. Если запись не найдена — 404, если ошибка на сервере — 500.
Самый распространённый стиль такого API — REST, где ресурсы (users, posts) адресуются через URL, а действия — через HTTP-методы. Важно, что API — это документированный контракт; его спецификация (например, OpenAPI) описывает, какие endpoints, методы, типы данных и коды ответов возможны. Без документации разработчики на другой стороне гадают, что отправлять.
Для Junior-разработчика ключевое — понимать, что клиент и сервер независимы, их связывает только API. Сервер можно переписать на другом языке, но если API не меняется, клиенты не заметят. И наоборот: клиент может быть любым — веб-приложение, мобильное приложение, curl — если он следует тому же контракту.