JSON ou SOAP (XML) ?

Question

Je suis en train de développer une nouvelle application pour l'entreprise. L'application doit échanger des données depuis et vers l'iPhone.

Le côté serveur de la société utilise le cadre .NET.

Par exemple : la classe "Client" (nom, adresse, etc.) pour un numéro de client spécifique devrait d'abord être téléchargée du serveur vers l'iphone, stockée localement et ensuite téléchargée de nouveau pour appliquer les changements (et les rendre disponibles aux autres personnes). La concurrence ne devrait pas poser de problème (du moins pour le moment...).

Dans tous les cas, je dois développer à la fois le côté serveur (webservice ou autre) et l'application iPhone.

Je suis libre d'identifier la meilleure façon de le faire (il s'agit de l'application "numéro UN", elle deviendra donc la "norme" pour l'avenir).

Alors, que me conseillez-vous ?

Utiliser les services web SOAP (analyse XML, etc.) ou utiliser JSON ? (cela semble plus léger...) Est-il clair pour moi comment "uploader" des données en utilisant SOAP (très long de coder l'enveloppe xml soap ... j'éviterais) mais comment puis-je faire la même chose en utilisant JSON ?

L'application doit utiliser des valeurs de date (par exemple : last_visit_date etc.). Qu'en est-il des dates dans Json ?

Answer 1

JSON présente plusieurs avantages par rapport à XML. Il est beaucoup plus petit et moins gonflé, de sorte que vous transmettrez beaucoup moins de données sur le réseau, ce qui, dans le cas d'un appareil mobile, fera une différence considérable.

Il est également plus facile à utiliser dans le code javascript car vous pouvez simplement passer le paquet de données directement dans un tableau javascript sans aucune analyse, extraction et conversion, ce qui est également beaucoup moins gourmand en ressources CPU.

Pour coder avec elle, au lieu d'une bibliothèque XML, vous voudrez une bibliothèque JSON. Les dates sont gérées comme vous le feriez avec XML - elles sont encodées selon une norme, puis la bibliothèque les reconnaît. (par exemple voici une bibliothèque avec un échantillon contenant des dates)

Voici une introduction .

Answer 2

Ah, la grande question : JSON ou XML ?

En général, je ne préfère le XML que lorsque j'ai besoin de faire circuler beaucoup de texte, car il excelle à envelopper et à baliser le texte.

Lorsque vous faites circuler de petits objets de données, où les seules chaînes de caractères sont petites (identifiants, dates, etc.), j'aurais tendance à utiliser JSON, car il est plus petit, plus facile à analyser et plus lisible.

Notez également que même si vous choisissez XML, cela ne signifie en aucun cas que vous devez utiliser SOAP. SOAP est un protocole très lourd, conçu pour l'interopérabilité entre partenaires. Comme vous contrôlez à la fois le client et le serveur ici, cela n'a pas nécessairement de sens.

Answer 3

Réfléchissez à la manière dont vous consommerez les résultats sur l'iPhone. Quel mécanisme utiliseriez-vous pour lire la réponse du service web ? NSXMLParser ?

La façon dont vous consommez les données a le plus grand impact sur la façon dont vous les servez.

JSON et SOAP sont-ils vos seules options ? Qu'en est-il des services RESTful ?

Jetez un coup d'œil à certains grands acteurs du web qui ont des API publiques accessibles aux clients iPhone :

API Twitter API FriendFeed

Consultez également les articles connexes suivants :

• Comment analyser le JSON imbriqué sur l'iPhone ?
• Service WCF RESTful pouvant toujours utiliser SOAP
• Performances de REST par rapport à SOAP

Answer 4

JSON présente les avantages suivants :

1. il peut encoder des valeurs booléennes et numériques ... en XML, tout est une chaîne de caractères.
2. il a une sémantique beaucoup plus claire ... en json vous avez {"key":"someValue"} En XML, vous pouvez avoir <data><key>someValue</key></data> ou <data key="someValue" /> ... tout nœud XML doit avoir un nom ... cela n'a pas toujours de sens ... et les enfants peuvent soit représenter des propriétés d'un objet, soit des enfants qui, lorsqu'ils apparaissent plusieurs fois, représentent en fait un tableau ... pour vraiment comprendre la structure objet d'un message XML, il faut le schéma correspondant ... en JSON, il faut uniquement le JSON ...
3. plus petit et utilise donc moins de bande passante et de mémoire pendant l'analyse et la génération ...

En dehors de cela, je ne vois AUCUNE différence entre XML et JSON ... je veux dire, c'est tellement interchangeable ... vous pouvez utiliser JSON pour capturer la sémantique de SOAP, si vous le souhaitez ... c'est juste que SOAP est si gonflé ... si vous voulez utiliser SOAP, utilisez une bibliothèque et des générateurs pour cela ... ce n'est ni amusant ni intéressant de tout construire à la main ...

l'utilisation de XML RPC ou JSON RPC devrait fonctionner plus rapidement ... c'est plus léger, et vous utilisez JSON ou XML à volonté ... mais lors de la création d'applications client<->serveur, une chose très importante à mes yeux, est d'abstraire la couche de transport des deux côtés ... toute votre logique commerciale etc. ne devrait en aucun cas dépendre de plus d'une minuscule interface, quand il s'agit de communication, et ensuite vous pouvez brancher des protocoles dans votre application, si nécessaire ...

Answer 5

Vous pourriez également utiliser Hessian en utilisant HessianKit du côté de l'iPhone, et HessianC# du côté du serveur.

Les gros bonus sont : 1. Hessian est un protocole de sérialisation binaire, donc des charges utiles de données plus petites, ce qui est bon pour la 3G et le GSM. 2. Vous n'avez pas à vous soucier du format à chaque extrémité, le transport est automatisé avec les proxies.

Ainsi, du côté serveur, il suffit de définir une interface C#, telle que :

public interface IFruitService {
  int FruitCount();
  string GetFruit(int index);
}

Il vous suffit ensuite de sous-classer CHessianHandler et d'implémenter IFruitService, et votre service web est prêt.

Sur l'iPhone, il suffit d'écrire le protocole Objective-C correspondant :

@protocol IFruitService
-(int)FruitCount;
-(NSString*)GetFruit:(int)index;
@end

Il est alors possible d'y accéder par procuration par une seule ligne de code :

id<IFruitService> fruitService = [CWHessianConnection proxyWithURL:serviceURL 
                                                          protocol:@protocol(IFruitService)];

Liens :

HessianKit : kit de hessian