Я думаю, что заявленный акцент на производительности противоречит реальным компромиссам.
Учтите, что кому-то придется поддерживать ваш код - если вы используете API, область тестирования мала, но API AWS могут измениться или устареть; если вы SDK, следующий программист подключит новую версию SDK и будет надеяться, что она работает, но если этого не произойдет, они увязнут в весе SDK.
Аналогично, представьте, что кто-то должен сделать обзор безопасности этого приложения или представить что-то, что еще не охватывалось SDK (давайте представим, что учетная группа распространяется от роли вызывающей стороны к базовому хранилищу).
Не думаю, что есть четкий ответ.
Вот мои предложения :
- поддерживать согласованность - API или SDK (в рамках данного приложения)
- рассмотрите более широкую картину (сколько приложений вы планируете написать?)
- не бойтесь переключиться на другой подход позже
Мне приходилось выбирать что-то подобное в прошлом с Docker (гораздо более приятные API и SDK / библиотеки). Вот как это разыгрывается:
Для тестирования мы использовали бета-версию привязок Docker Python: версии prod не хватало, а привязки (ваш SDK) в целом были довольно хорошими и понятными.
Для очистки журнала я использовал HTTP-вызовы (ваш API), «потому что производительность», в действительности сравнительная умственная нагрузка с использованием API против SDK и потому что привязки (SDK) не поддерживали asyncio.