Ну вообще всё завист от целей создания API и способов его использования.
1. Если целевой сервис доступен по telnet, то вполне логично использовать telnetlib.
У http куча накладных расходов и куча лишнего в запросах и ответах,
кроме того, он всётаки больше подходит для REST-приложеинй (управление ресурсами), а у вас, судя по всему RPC-style (вызов функций).
2. Если в куче методов необходимо выполнять одни и теже манипуляции, то вполне очевидно объединить эти манипуляции в общий метод.
Но если ваша обёртка не обладает состоянием и не инкапсулирует никакие данные (например, параметры авторизации или доступа к сервису) - то это модуль, а не класс.
И уж темболее не стоит использовать классы из питона 2.0
3. зависит от того, образует ли множество методов имеющие смысл независимые подмножества. (например метод, использующие только Аккаунт)
4. необходимость в классах Аккаунт, Сервер, Кластер, Правило зависит от того, являются ли они классами в смысле ООП: инкапсулируют ли какието данные (или просто содержат примитивы), содержат ли какие-то методы манипуляции с ними.
Вариантов глобально два:
1. возвращать инстансы этих классов и принимать их параметрами из методов вашей обёртки api
т.е. сделать классы просто типизированными контейнерами данных
2. перенести вызовы api в методы этих классов, ну и засунуть в них ссылку на порождающий их экземпляр api.
Зависит от того, существуют ли вообще такие методы api, которые однозначно идентифицируются как методы какого-либо класса.
