Что такое curl и для чего он используется?

Что проверяют

Умеете ли вы проверять API без интерфейса и без Postman: воспроизвести баг одной командой, приложить её к задаче, обратиться к эндпоинту с сервера, где нет графической оболочки. Следом просят написать POST с JSON и токеном или спрашивают, как увидеть заголовки ответа.

Как отвечать

curl это консольная утилита и библиотека libcurl для передачи данных по URL. Поддерживает HTTP и HTTPS, FTP, SFTP и десятки других протоколов, есть в macOS, Linux и Windows 10 и новее. Для QA главное это HTTP:

• метод и тело: -X задаёт метод, -d отправляет данные и сам переключает запрос на POST, --json '{"a":1}' (с версии 7.82) заодно ставит Content-Type и Accept в application/json, -F отправляет файл как multipart/form-data;
• заголовки и авторизация: -H "Authorization: Bearer ...", -u user:pass для Basic, -b и -c для чтения и сохранения cookies;
• ответ: -i выводит заголовки вместе с телом, -I отправляет HEAD, -v показывает весь обмен, включая TLS, -L идёт по редиректам;
• для скриптов: -s без прогресса, -w '%{http_code}' печатает код ответа, --fail даёт ненулевой код выхода на статус 400 и выше, --max-time ограничивает ожидание.

На практике в DevTools есть Copy as cURL, и баг из браузера за секунду превращается в воспроизводимую команду, а Postman умеет импортировать такую команду. curl помогает проверить, что сервер валидирует данные сам, а не полагается на форму, и годится для смоук-проверок после деплоя в CI.

Где спотыкаются

Считают, что curl завершится ошибкой на ошибке сервера. Без --fail ответ 404 или 500 даёт код выхода 0, и проверка в пайплайне остаётся зелёной.

Путают -i и -I. Второй отправляет HEAD, а часть серверов отвечает на него иначе, чем на GET, и баг не воспроизводится.

Вставляют в баг-репорт команду из Copy as cURL целиком, с живым Authorization и cookies сессии. Токен из тикета видят все, у кого есть доступ к трекеру, поэтому такие заголовки вырезают.