l'impact principal dans la vitesse du savon par rapport au repos n'a pas à voir avec la vitesse du fil, mais avec la possibilité de mise en place. REST suggère d'utiliser la sémantique du web au lieu d'essayer de le passer en tunnel via XML, de sorte que les services web RESTful sont généralement conçus pour utiliser correctement les en-têtes de cache, de sorte qu'ils fonctionnent bien avec l'infrastructure standard du web comme les proxies de cache et même les caches de navigateur local. En outre, l'utilisation de la sémantique du web signifie que des choses comme les ETags et la compression zip automatique sont bien compris façons d'accroître l'efficacité.

..et maintenant tu dis que tu veux des points de repère. Eh bien, avec L'aide de Google, j'ai trouvé un gars dont les tests montrent que le repos est 4-6x plus rapide que le savon et un autre papier qui favorise également le repos.

RESTE comme un protocole ne définit pas la forme de l'enveloppe du message, tandis que le SAVON n'ont la présente norme.

donc, c'est quelque peu simpliste d'essayer de comparer les deux, ce sont des pommes aux oranges.

cela dit, une enveloppe SOAP (moins les données) n'est que de quelques k, donc il ne devrait pas y avoir de différence notable de vitesse à condition que vous récupériez un objet sérialisé à la fois par SOAP et REST.

SOAP et tout autre protocole qui utilise XML gonfle généralement vos messages un peu - cela peut ou non être un problème selon le contexte.

quelque chose comme JSON serait plus compact et peut - être plus rapide à sérialiser / deserialiser-mais ne l'utilisez pas exclusivement pour cette raison. Faire ce que vous vous sentez un sens au temps et de la modifier si c'est un problème.

Tout ce qui utilise HTTP typiquement (sauf s'il réutilise un HTTP 1.1 keepalive connection, que de nombreuses implémentations ne font pas) lance une nouvelle connexion TCP pour chaque requête; c'est assez mauvais, surtout sur les liens à haute latence. HTTPS est bien pire. Si vous avez beaucoup de court demandes provenant d'un expéditeur à un destinataire, pensez à comment vous pouvez prendre ce traitement.

utiliser HTTP pour n'importe quel type de RPC (que ce soit SOAP ou autre chose) va toujours entraîner ce overhead. Les autres protocoles RPC vous permettent généralement de garder une connexion ouverte.

développant la réponse de" pjz".

si vous recevez beaucoup d'informations(type d'appels*) basées sur les opérations SOAP, il n'y a actuellement aucun moyen de les mettre en cache. Mais si vous deviez mettre en œuvre ces mêmes opérations en utilisant REST, il est possible que les données(dépend de votre contexte commercial) puissent être mises en cache, comme mentionné ci-dessus. Parce que SOAP utilise POST pour ses opérations, il ne peut pas mettre l'information en cache du côté du serveur.

est certainement plus lent. Les charges utiles sont beaucoup plus importantes et plus lentes à assembler, à transporter, à analyser, à valider et à traiter.

Je ne sais pas de réponse à la question de benchmarking, cependant, ce que je sais À propos du format SOAP est oui, il a des frais généraux, mais ces frais généraux n'augmentent pas par demande: si vous avez un élément envoyé au service web, vous avez Frais Généraux + construction d'un élément, et si vous avez 1000 éléments envoyés au service web, vous avez Frais Généraux + construction de 1000 éléments. Les frais généraux se produisent lorsque la requête XML est formatée pour l'opération particulière, mais chaque individu argument élément de la requête est formaté de la même.

si vous vous en tenez à des courtes salves de données reproductibles (disons 500 éléments), la vitesse devrait être acceptable.

je suppose que la question principale ici est comment compare RPC avec SOAP.

ils servent tous les deux la même approche d'abstraction de communication en ayant des objets tronqués que vous opérez avec et des types de données primitifs/complexes que vous obtenez en arrière sans vraiment savoir comment tout cela est traité en dessous.

je préfère toujours (JSON)RPC parce que

• c'est léger
• il y a beaucoup de grands des implémentations pour tous les langages de programmation
• il est simple à apprendre/utiliser/créer
• il est rapide (surtout avec JSON)

bien qu'il y ait des raisons d'utiliser SOAP, c'est-à-dire si vous avez besoin de paramètres de nommage au lieu de compter sur leur ordre correct

plus de détails vous obtenez de ce stackoverflow question