Работали ли вы с HTTP через фреймворки и инструменты типа curl или Postman?

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

Понимаете ли вы сам протокол, а не одну библиотеку, и умеете ли воспроизвести проблему снаружи приложения. Для питониста это ещё вопрос про надёжность клиента: таймауты, повторы, переиспользование соединений.

Как отвечать

Назовите инструменты и объясните, зачем каждый. В коде requests для скриптов и синхронных сервисов, httpx когда нужен asyncio, aiohttp в асинхронном приложении. Детали, по которым видно опыт:

• клиент создаётся один раз (Session или Client) и переиспользуется, иначе на каждый вызов новое соединение и новое рукопожатие TLS;
• таймаут задаётся всегда: у requests его по умолчанию нет, и зависший сервер держит воркер бесконечно;
• повторы только для идемпотентных запросов, через HTTPAdapter с Retry и растущей паузой, с уважением к Retry-After в ответе 429;
• код ответа разбирается осознанно: 4xx это ошибка нашего запроса, 5xx чужая, и raise_for_status не заменяет обработку.

Про инструменты скажите так: curl -i показывает заголовки, curl -v рукопожатие и редиректы, этого хватает, чтобы отделить проблему сети от проблемы кода. Postman удобен для коллекций и окружений, но в репозиторий лучше класть команду curl или тест на pytest с подменой транспорта, чтобы проверка жила в CI, а не в чужом аккаунте.

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

Путают params, data и json в requests. Аргумент json= сам сериализует тело и ставит заголовок типа контента, data= со словарём отправит форму, сервер ответит 400, а кандидат ищет ошибку в чужом API.

Второе: ходят без таймаута и без пула соединений. На стенде незаметно, в проде один медленный внешний сервис выедает все воркеры, и падает приложение целиком, а не одна ручка.

Третье: читают тело целиком. Большой ответ уходит в память одним куском, хотя есть потоковое чтение по частям. Рядом та же ошибка с кодировкой: text угадывает её по заголовку, и на кривом заголовке получается мусор вместо явного декодирования.