J'étudie actuellement l'implémentation d'un client qui utilisera une API de gestion SOAP étendue existante.

J'ai examiné différentes implémentations SOAP comme pysimplesoap et SUDS. Alors que le premier a eu des problèmes d'analyse du WSDL à cause de trop de récursions, la mousse a bien fonctionné (mais lentement) et j'aime vraiment le module.

Cependant, il semble y avoir plusieurs problèmes avec SUDS comme la consommation de mémoire élevée, la vitesse d'analyse WSDL et la prise en charge manquante de certains attributs WSDL (par exemple, l'attribut de choix).
Bien que de nombreuses personnes commettent activement des rapports de bogues et des correctifs, il n'y a aucune version de SUDS depuis 0.4 le 2010-09-15. De plus, le wiki et la feuille de route semblent un peu négligés.

Pour moi, il semble que SUDS ne soit plus maintenu.

Voici donc mes questions:

  1. Est-il judicieux de baser un projet plus large sur suds en tant que client soap?
  2. Existe-t-il un fork de mousse qui implémente déjà certains des correctifs disponibles dans le système de billetterie?
  3. Quelles sont les alternatives disponibles, qui ont une empreinte mémoire inférieure et sont faciles à utiliser et peuvent gérer des fichiers WSDL volumineux complexes

[Mise à jour de novembre 2013]

Plus de deux ans se sont écoulés et il s'avère que le projet de mousse original est vraiment mort. Il n'y a eu aucune autre version depuis 2010. En raison de ce fait, beaucoup de gens ont commencé à forger des suds et des distributions comme Debian déploient des versions corrigées du paquet suds d'origine pour résoudre certains des problèmes.

Je peux recommander la fourche activement entretenue de Jurko que j'ai utilisée avec succès. Il prend en charge python 3 et résout de nombreux problèmes connus de la mousse. Les notes de publication et le suivi des bogues sont disponibles sur Bitbucket, le package est également disponible sur PyPI afin qu'il puisse être installé à l'aide de pip.

62
circus 12 oct. 2011 à 15:49

4 réponses

Meilleure réponse

Bien qu'il n'y ait pas de norme certifiée, si vous devez utiliser SOAP, Suds est votre meilleur choix. Les soudains peuvent être lents sur les grands WSDL, et c'est quelque chose sur lequel ils travaillent.

En attendant, si vous ne vous attendez pas à ce que votre WSDL change souvent, vous avez deux options qui peuvent vous acheter beaucoup de vitesse:

  1. Téléchargement de votre WSDL sur localhost
  2. Utilisation de la mise en cache

Téléchargement de votre WSDL

Avec les grands WSDL, une partie du problème est que vous devez d'abord télécharger le WSDL à chaque fois, ce qui peut ajouter des frais généraux. Suds prendra le temps de télécharger et d'analyser l'intégralité du WSDL au démarrage pour s'assurer qu'il n'a pas changé.

Si vous pouvez le télécharger sur le système local, puis le transmettre au constructeur Client en utilisant un schéma file:// dans l'URL. Puisque Suds utilise urllib2 pour le transport HTTP, cela est parfaitement légitime.

Maintenant, comme vous ne fournissez pas de nom d'hôte dans votre URL WSDL, vous devrez également passer un argument location spécifiant l'URL réelle de l'application SOAP.

Voici un exemple:

from suds.client import Client

# The service URL
soap_url = 'http://myapp.example.notreal/path/to/soap'

# The WSDL URL, we wont' use this but just illustrating for example. This 
# would be the file you download to your system and save as wsdl_file
wsdl_url = 'http://myapp.example.notreal/path/to/soap?wsdl' 

# The full path to the downloaded WSDL file on your local system
wsdl_file = '/path/to/myapp.wsdl'
wsdl_url = 'file://' + wsdl_file # Override original wsdl_url

client = Client(url=wsdl_url, location=soap_url)

Si vous êtes intéressé, j'ai utilisé cette approche dans mon travail et j'ai open source le code.

Mise en cache de votre WSDL

L'autre option consiste à utiliser l 'excellente fonctionnalité de mise en cache de Suds. Vous devez créer explicitement un objet cache, puis le transmettre au constructeur à l'aide de l'argument cache. Sinon, il s'agit par défaut d'un ObjectCache d'une durée de 1 jour.

Vous pouvez également envisager d'utiliser ces deux approches.

48
jathanism 21 oct. 2011 à 17:23

Il existe un nouveau client SOAP bien entretenu appelé zeep. Il prend en charge Python 2 et 3 et est basé sur des bibliothèques lxml et de requêtes bien connues.

12
chhantyal 13 mai 2016 à 10:42

Un article à jour intéressant peut être trouvé ici: Quelles bibliothèques client SOAP existent pour Python, et où est la documentation pour elles? Malheureusement, la bibliothèque SOAP parfaite que vous recherchez ne semble pas (encore) exister

7
Community 23 mai 2017 à 10:31

Nous sommes en 2013. Il s'agit d'une mise à jour pour tous ceux qui ont rencontré le problème avec Python et SOAP comme moi.

J'essayais d'utiliser SOAP en Python. J'ai essayé la mousse, mais malheureusement, la bibliothèque n'a pas été mise à jour depuis 2010. Lors du premier test de mon code, j'ai reçu cette erreur:

RuntimeError: maximum recursion depth exceeded while calling a Python object

Ce qui s'avère être un problème que suds a avec les références récursives sur les connexions HTTPS. Voir la réponse de drfence. J'ai dû patcher manuellement la mousse pour éviter ce problème.

Je suis passé à php à la place. Pas aussi simple que python, mais j'ai pu le faire fonctionner.

5
Community 23 mai 2017 à 11:47
7739613