web-dev-qa-db-fra.com

JSON ou SOAP (XML)?

Je développe une nouvelle application pour l'entreprise. L'application doit échanger des données depuis et vers l'iPhone.

Côté serveur de l'entreprise utilise le framework .NET.

Par exemple: la classe "Client" (nom, adresse, etc.) pour un numéro de client spécifique doit d'abord être téléchargée du serveur vers l'iphone, stockée localement puis téléchargée pour appliquer les modifications (et les mettre à la disposition d'autres personnes). La concurrence ne devrait pas être un problème (au 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 (c'est l'application "numéro UN" donc elle deviendra la "norme" pour l'avenir).

Alors, que me proposez-vous?

Utiliser SOAP services Web (analyse XML etc.) ou l'utilisateur JSON? (Il semble plus léger ...) Est-il clair pour moi comment "télécharger" des données en utilisant SOAP (très long pour coder l'enveloppe xml soap ... j'éviterais) mais comment puis-je faire de même en utilisant JSON?

L'application doit utiliser des valeurs de date (par exemple: last_visit_date etc.) et la date dans Json?

iphoneobjective-cjsonsoap
48
Fulkron

JSON présente plusieurs avantages par rapport à XML. C'est beaucoup plus petit et moins gonflé, vous passerez donc 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 analyse, extraction et conversion, il est donc beaucoup moins gourmand en CPU.

Pour coder avec, 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 - encodez-les en standard, puis laissez la bibliothèque les reconnaître. (par exemple voici une bibliothèque avec un échantillon contenant des dates)

Voici une introduction .

41
gbjbaanb

Ah, la grande question: JSON ou XML?

En général, je préférerais XML uniquement lorsque j'ai besoin de faire circuler beaucoup de texte, car XML excelle dans l'habillage et le marquage du texte.

Lors du passage de petits objets de données, où les seules chaînes 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 les partenaires. Comme vous contrôlez le client et le serveur ici, cela n'a pas nécessairement de sens.

33
Avi

Considérez comment vous utiliseriez 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 aurait 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 œil à certains grands acteurs du Web qui ont des API publiques accessibles aux clients iPhone:

API TwitterAPI FriendFeed

Consultez également les articles connexes suivants:

9
JBRWilkinson

JSON présente les avantages suivants:

  1. il peut encoder des valeurs booléennes et numériques ... en XML tout est une chaîne
  2. il a une sémantique beaucoup plus claire ... dans 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 représenter les propriétés d'un objet ou les enfants qui, lorsqu'ils se produisent plusieurs fois, représentent en fait un tableau ... à comprendre vraiment la structure d'objet d'un message XML, vous avez besoin de son schéma correspondant ... en JSON, vous avez besoin du JSON seulement ...
  3. plus petit et utilise donc moins de bande passante et de mémoire lors de l'analyse/génération ...

à part ça, 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 voulez ... c'est juste que SOAP est tellement 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 ...

en utilisant XML RPC ou JSON RPC devrait fonctionner plus rapidement ... il 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 le couche de transport des deux côtés ... toute votre logique métier, etc. ne devrait en aucun cas dépendre de plus qu'une petite interface, en matière de communication, et vous pourrez ensuite brancher des protocoles dans votre application, si nécessaire ...

9
back2dos

Il y a plus d'options que simplement SOAP vs JSON. Vous pouvez faire un protocole basé sur REST ( Representational State Transfer ) en utilisant XML. Je pense que c'est une utilisation plus facile que SOAP et vous obtenez un XSD beaucoup plus agréable (que vous concevez.) Il est assez facile pour presque n'importe quel client d'accéder à de tels services.

D'un autre côté, les analyseurs JSON sont disponibles pour presque toutes les langues et facilitent les appels depuis JavaScript si vous les utilisez via AJAX.

Cependant, SOAP peut être assez puissant avec des tonnes d'extensions standardisées qui prennent en charge les fonctionnalités d'entreprise.

4
Norman

Vous pouvez également utiliser Hessian en utilisant HessianKit du côté iPhone et HessianC # du côté serveur.

Les gros bonus sont: 1. Hessian dans un protocole de sérialisation binaire, donc des charges utiles de données plus petites, bonnes pour la 3G et le GSM. 2. Vous n'avez pas à vous soucier du format à l'une ou l'autre extrémité, le transport est automatisé avec des procurations.

Donc, côté serveur, vous définissez simplement une interface C #, telle que:

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

Ensuite, il vous suffit de sous-classer CHessianHandler et d'implémenter IFruitService, et votre service Web est terminé.

Sur l'iPhone, écrivez simplement le protocole Objective-C correspondant:

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

Celui-ci peut alors être accessible par proxy par une seule ligne de code:

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

Liens:

HessianKit: hessiankit

4
PeyloW

J'irais certainement avec JSON, comme d'autres l'ont déjà noté - c'est plus rapide et la taille des données est plus petite. Vous pouvez également utiliser un cadre de modélisation de données comme JSONModel pour valider la structure JSON et pour convertir automatiquement des objets JSON en objets Obj-C.

JSONModel comprend également des classes pour la mise en réseau et l'utilisation des API - comprend également des méthodes json rpc.

Jetez un œil à ces liens:

Petit exemple d'utilisation de JSONModel: http://www.touch-code-magazine.com/how-to-make-a-youtube-app-using-mgbox-and-jsonmodel/

J'espère que ceux-ci sont utiles

1
Marin Todorov