Je ne veux pas commencer une guerre sainte ici, mais la plupart des services Internet (flickr, twitter, facebook et autres) ont abandonné SOAP au profit des services Web RESTful et JSON comme format sérialisé. Bien qu'ils soient essentiellement les mêmes, les services REST s'appuient sur la méthode url et http pour définir ce qui doit être fait, par exemple
GET /articles - list all articles
POST /articles - add a new article
PUT /articles/123 - update article 123 with new data
JSON - décrit dans json.org - est également plus simple que XML, et peut-être pas pertinent, vous économisera quelques octets par demande. En suivant l'exemple précédent, voici comment un article serait décrit en notation JSON:
{
"id": 123,
"author": "Cyril",
"content": "Hello, this is an article",
"tags": [ "gamedev", "webservices", "multiplayer" ]
}
Pour l'IOS, il y a ce bel article http://petermcintyre.wordpress.com/2010/11/04/consume-json-rest-in-ios/ qui mentionne
http://code.google.com/p/json-framework / pour l'analyse et la génération des données.
Au tour par tour, vous pouvez compter sur les sessions http sur le serveur pour maintenir l'état, il n'est donc pas nécessaire de conserver une connexion socket persistante au serveur. Tout langage côté serveur prend en charge cela (php, python, java, etc.).
Cette architecture vous permet d'évoluer horizontalement (en ajoutant plus de serveurs) de manière transparente.
Je pense que l'utilisation de SOAP ou même de HTTP est exagérée. Définissez simplement votre propre protocole sur des connexions TCP vanille. Par exemple, interprétez chaque ligne de texte envoyée comme une commande. Définissez les commandes / réponses que le client et le serveur sont autorisés à envoyer.
Le FICS fonctionne de cette façon et il sert des milliers de joueurs d'échecs depuis de nombreuses années. IRC fonctionne également de cette façon (voir RFC 1459).
la source