No me refiero a comenzar una guerra santa aquí, pero la mayoría de los servicios de Internet (flickr, twitter, facebook y demás) han dejado caer SOAP a favor de los servicios web RESTful y JSON como formato serializado. Aunque esencialmente lo mismo, los servicios REST se basan en el método url y http para definir lo que se debe hacer, por ejemplo
GET /articles - list all articles
POST /articles - add a new article
PUT /articles/123 - update article 123 with new data
JSON, descrito en json.org, también es más simple que XML, y aunque tal vez sea irrelevante, le ahorrará algunos bytes por solicitud. Siguiendo el ejemplo anterior, así es como se describiría un artículo en notación JSON:
{
"id": 123,
"author": "Cyril",
"content": "Hello, this is an article",
"tags": [ "gamedev", "webservices", "multiplayer" ]
}
Para el IOS hay este bonito artículo http://petermcintyre.wordpress.com/2010/11/04/consume-json-rest-in-ios/ que menciona
http://code.google.com/p/json-framework / para analizar y generar los datos.
Al estar basado en turnos, puede confiar en las sesiones http en el servidor para mantener el estado, por lo que no es necesario mantener una conexión de socket persistente al servidor. Cualquier lenguaje del lado del servidor lo admite (php, python, java, etc.).
Esta arquitectura le permite escalar horizontalmente (agregando más servidores) de manera transparente.
Creo que usar SOAP o incluso HTTP es excesivo. Simplemente defina su propio protocolo sobre conexiones TCP de vainilla. Por ejemplo, interprete cada línea de texto enviada como un comando. Defina qué comandos / respuestas puede enviar el cliente y el servidor.
FICS funciona de esa manera y ha estado sirviendo a miles de jugadores de ajedrez durante muchos años. IRC también funciona de esa manera (ver RFC 1459).
fuente