Обновить

Комментарии 11

Выглядит круто и полезно. Пока не знаю куда применить, но буду держать в уме. Спасибо за то, что поделились!

Если есть спецификация API в формате OpenAPI, гораздо проще сгенерировать обертку для всего сразу с помощью OpenApiGenerator (для очень большого количества языков, не только Python). Также, для своего API, можно и контроллер для серверного кода сделать.

согласен, это очень удобная идея, однако здесь есть нюанс

я изучал последний раз это примерно полгода назад, и вывод все еще таков, что оно обычно генерирует код такого качества, что этим конечно можно пользоваться, но не очень-то и хочется

у меня в планах сделать опенапи генератор с использованием unihttp, но до этого дойдут руки немного позже

Я мало пользовался им для Python, но много использовал для Java, и на качество сгенерированного кода пожаловаться не могу. Собственно, он генерируется на этапе сборки, его не нужно читать, он валидный и работает - остается только использовать. Бывало, что классы модели получались странными, но связано это было с кривизной спецификации (исправлялась спецификация - выпрямлялись и модели). Ну и для случая, когда генератор чего-то не делает или делает не так, как было нужно, всегда есть возможность исправить шаблоны.

Без генератора писать код API-клиента в случае большого API (большой, это десятки разделов/подмодулей и сотни endpoint'ов, например, как у Amazon Ads) идея безумная.

Так же есть очень хороший подход specification first, когда все контракты заранее известны, а код вторичен. Меняем спеку - меняется код, не наоборот. И из спеки автоматом получаем документацию и набор тестов.

Пользовался около 2ух лет опенапи генератором на питоне.

Anyof с nullable возникли проблемы, отказывался принимать None/или вообще ничего.

С новой версией это вроде пофиксили, но поломалась совместимость со старыми openapi где null через required прописан.

Возможно щас дела обстоят лучше, я уже не слежу, потому что пересели на aiohttp

не пропустил, но у Тишки в descanso используется все же немного иной подход к формированию клиентов, который лично мне не очень нравится

моя библиотека больше вдохновлена https://github.com/IvanKirpichnikov/retejo, но увы, Иван ее забросил

Оно, конечно, замечательно, но через условные полгода-год на месте Ивана вы не окажитесь ?)

что будет через полгода-год, пожалуй, мало кто знает)

но я сомневаюсь, что оно перестанет быть мне нужным

Да, выглядит круто,! В доке ничего не увидел про повторы и их настройку (например 400, 404 или 401 ошибку смысла нет повторять, а вот 500 или таймаут - нужно, но с настройкой экспоненциального времени между попытками, желательно ограничить ещё и общее время на операцию, число попыток)

Сейчас для такого использую https://github.com/hynek/stamina очень удобно, спасает от сетевых проблем

в библиотеке есть мидлварь встроенная (правда я не подсветил это в ридми): https://github.com/goduni/unihttp/blob/master/src/unihttp/middlewares/retry.py, базовые случаи, полагаю, она решает спокойно

но я подумаю, возможно получится сделать удобную интеграцию с той же stamina для более продвинутой поддержки, потому что верная мысль в общем

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации