Coût de la sérialisation dans le service Web

Question

Mon prochain projet concerne la création d'une API de données dans un environnement d'entreprise. Les données seront consommées par plusieurs applications fonctionnant sur différentes plates-formes logicielles. Alors que mes collègues préfèrent généralement SOAP, j'aimerais utiliser une architecture RESTful.

La plupart des applications n'ont besoin que de quelques objets à chaque appel. D'autres applications devront cependant parfois faire plusieurs appels séquentiels impliquant chacun des milliers d'enregistrements. Je suis préoccupé par la performance. Sérialisation/désérialisation & utilisation du réseau sont où je crains de trouver un goulot d'étranglement. Si chaque requête implique un retard important, toutes les applications de l'entreprise seront lentes.

Mes craintes sont-elles réalistes? La sérialisation vers un format volumineux comme XML ou JSON sera-t-elle un problème? Existe-il des alternatives? Dans le passé, nous avons dû effectuer ces transferts de données volumineux en utilisant un format de fichier plus "plat" ou plus léger, tel que le format CSV, pour des performances optimales. Comment puis-je espérer obtenir les performances dont j'ai besoin en utilisant un service Web?

Bien que je préfère les réponses spécifiques à REST, je suis curieux de savoir comment les utilisateurs de SOAP pourraient également traiter cela.

Answer 1

Nous offrons à la fois XML et JSON. Votre temps de rendu mentionné peut vraiment être un problème. Du côté serveur, nous avons JAXB dont l'implémentation standard du soleil est quelque peu lente, quand il s'agit de marshall XML. Le langage XML présente l'inconvénient de la verbosité, mais il est également intéressant en termes d'interopérabilité et possède un schéma + versionnage explicite.

Nous avons compensé la verbosité de plusieurs façons (limitant notamment le jeu de résultats):

• Si vous avez un récipient avec des articles qu'il contient, offre la pagination dans votre réponse xml (à la fois la taille de page et page -numéro, p.ex./items? page = 0 & size = 3). Le client peut lui-même réduire la taille en réduisant la taille de la page.
• Offre des éléments de regroupement, par exemple plusieurs clients ne sont intéressés que par un champ de données de l'ensemble de votre article. Pour ce faire, avec un paramètre (par exemple/items? Select = name), seul l'élément imbriqué 'name' est inclus dans la ligne de votre élément item. Cela réduit considérablement la taille.

Généralement, les clients ont le pouvoir d'utiliser la limitation de l'ensemble de résultats. Ils vont certainement l'utiliser, car il accélère le temps de réponse aussi de leur côté :)

Également utiliser la compression, il réduit considérablement le XML verbeux (dans notre cas la charge utile est 10 fois plus petite). Du côté client, vous pouvez le faire par l'entête 'Accept-Encoding: gzip'. Si vous utilisez Apache, la configuration du serveur est également simple

Answer 2

Un avantage de REST est que vous êtes libre d'utiliser le type de média que vous voulez. Pourquoi ne pas continuer à utiliser text/csv? Vous pouvez également activer la compression HTTP pour réduire davantage la consommation de bande passante.

Les services REST sont parfaits pour tirer parti de différents types de formats de données. Quel que soit le format qui correspond le mieux à votre scénario.

Answer 3

Je voudrais proposer trois lignes directrices:

1. on est l'observation qu'il ya beaucoup de services Web SOAP là-bas (en particulier construit avec la technologie .NET 2.0 « ASMX ») qui envoient leurs données vers le bas transfert d'objets sérialisé en XML. Il y a bien sûr beaucoup de services RESTful qui envoient XML ou JSON. La sérialisation/désérialisation XML est rarement le facteur contraignant. Une cause fréquente de goulets d'étranglement dans les services Web est une interface qui encourage les applications client à obtenir des données en effectuant ces milliers d'appels séquentiels (il existe un terme pour cela: une interface chatty). C'est ce que vous devez éviter lorsque vous concevez l'interface de votre service Web, quel que soit l'acronyme à quatre lettres que vous décidez d'utiliser. Une chose à retenir à propos de REST est qu'il représente (partiellement) un transfert d'état, ce qui peut être mal adapté à certaines opérations où vous ne voulez pas transférer l'état d'un objet métier du serveur vers un application client. Dans ces cas, un service Web SOAP (comme suggéré par vos collègues) est plus approprié; ou peut-être une combinaison de services SOAP et REST, où les services REST s'occuperaient des opérations où le transfert d'état est approprié, et les services SOAP mettraient en œuvre le reste (jeu de mots non intentionnel :-)) des opérations.