Добрый день. Стоит перед мной задача разработки и написания API сервера с использование фреймворка Twisted.
К API серверу должны подключатся клиентские приложения и держать постоянное соединение с им. И если с написанием сервера все более-менее понятно, то с структурой API возникла целая дилема.
Основным критерием API является его простота для использования сторонними разработчиками. Из возможных вариантов рассматриваю REST, SOAP, XML-RPC. Почти неделю бьюсь над этим вопросом и все так же не знаю чему отдать предпочтение.
Как по мне то REST почти не годится для работы с постоянными соединениями, так-как он изначально расчитан на работу вида запрос —- ответ.
SOAP громоздок и более тяжелый в плане избыточности данных, но зато хорошо документирован и вроде как является стандартом.
Ну а XML-RPC он и в африке XML-RPC, вот только не знаю будет ли правильно делать API на нем.

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

Зависит от задачи, инфраструктуры и сервисов, которые вы планируете реализовывать

Немного опишу планируемый процесс работы:
клиентское приложения подключается к API серверу, авторизируется и не закрывает данное соединение. Далее начинает вызывать разные методы - например подключается к обмену данными с другими такими же клиентскими приложениями, так же может получать и размещать данные на самом сервере, а так же сервер иногда может обращаться к самому приложению, и все это должно происходить в пределах одного подключения к серверу.
Клиентское приложение - это оффлайн декстопный софт, который никак не привязан к вебу (но все же хотелось создать API работающее поверх http), но как я вижу работать напрямую с сокетами будет намного проще. Будет ли это правильно с точки зрения построения удаленного сервиса?

Vetal_krot
но все же хотелось создать API работающее поверх http

Если хотите работать поверх http - сделайте реализацию comet (он же long polling). Тут уж как вам хочется, гоняйте себе данные хоть в xml, хоть в json (этот мне больше по душе, тем более при работе с Python).
Если кратко - делаете вебсайт (фабрику), цепляете к нему ресурсы. Ресурс на render_GET (или render_POST) возвращает NOT_DONE_YET, при этом запуская deferred, который будет слушать сообщения (если вам нужны обмены данными с другими клиентами, у вас скорее всего будет какой-нибудь брокер задач (RabbitMQ, например), который будет обслуживать очереди вот этих вот сообщений.

Если не http - делаете сервер на tcp протоколе, ну а дальше дело техники. Опять же таки можете использовать свой json или xml протокол для обмена (он в обоих случаях вполне может быть одинаковым). В контексте вашей задачи делать SOAP - это сильно лишнее. SOAP больше подходит тогда, когда у вас распределенные реюзабельные сервисы, например канонический ESB (Enterprise Service Bus), но у вас такая тенденция не просматривается. В реализации протокола, если паки даных у вас небольшие, можно вполне использовать LineReceiver. Работает по принципу: получил строку по сокету - обработал - отдал ответ.

Вот такой вот сумбурчик.

Хотел спросить, стоит ли использовать стандартный XMLRPC сервер который идет из коробки для решения моих задач?

Vetal_krot, а почему бы и нет? Ведь суть этого сервера в том, что он предоставляет базовый функционал, а вы просто-напросто дописываете методы, которые обрабатывают удаленные процедуры. Мне так сходу трудно придумать ситуацию, когда этот сервер не подошел бы.