FastAPI для клиента: как должны выглядеть API-клиенты в PythonPython-сообщество отлично научилось делать 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
