🖥 FastAPI для клиента: как должны выглядеть API-клиенты в Python

Python-сообщество отлично научилось делать API-серверы.
FastAPI / DRF дают идеальный опыт разработчика:
- типы
- валидация
- понятные эндпоинты
- документация по OpenAPI
- минимум рутины

Но есть проблема.

Серверы стали удобными и “правильными”, а вот клиентская сторона до сих пор часто выглядит как кустарщина.

Что часто встречается в проектах на базе python:
- везде раскиданы httpx.get/post
- URL собираются руками
- параметры и headers копируются по коду
- ответы парсятся вручную
- ошибки обрабатываются как попало
- нет нормальных типов и автодополнения

И именно тут часто появляется 80% проблем.
API может быть идеально спроектирован, но пользоваться им неудобно.

Да, можно сгенерировать кода клиента.
Но чаще всего генератор выдаёт огромный неудобный код:
- странные имена методов
- перегруженные классы
- нечитаемый boilerplate
- всё равно приходится писать обёртки руками

В итоге клиенты либо не генерируют вообще, либо генерируют и потом ненавидят.

API-клиенты должны быть сделаны как фреймворк.
Как FastAPI, только наоборот.

То есть ты описываешь клиент красиво и декларативно:
- функция описывает intent (что мы делаем)
- типы описывают контракт
- библиотека берёт на себя HTTP-рутину

Вместо кода “на коленке”
httpx.get("https://api.site.com/users/123")

Должно быть
get_user(123)

И дальше библиотека сама:
- соберёт URL
- подставит параметры
- сериализует запрос
- выполнит HTTP
- распарсит ответ
- кинет нормальную ошибку
- даст типы и автодополнение в IDE

Именно эту идею автор статье и продвигает (проект Clientele)
Сделать API-клиенты удобными, чистыми и типобезопасными
так же, как мы привыкли делать серверы

Проблема не в HTTP.
Проблема в том, что API-клиенты в Python до сих пор не стали “первоклассным кодом”.

А должны стать.

Подробности: paulwrites.software/articles/python-api-clients