Python SOAP Client - usa SUDS o qualcos'altro?

Question

Attualmente sto cercando di implementare un client che utilizzi un'API di gestione SOAP estesa.

Ho esaminato diverse implementazioni SOAP come pysimplesoap e SUDS. Mentre il primo ha avuto problemi nell'analisi del WSDL a causa di troppe ricorsioni, suds ha funzionato bene (ma lento) e mi piace molto il modulo.

Tuttavia, sembrano esserci diversi problemi con SUDS come l'elevato consumo di memoria, la velocità di analisi WSDL e il supporto mancante per alcuni attributi WSDL (ad esempio l'attributo choice).
Mentre ci sono un sacco di persone che pubblicano attivamente segnalazioni di bug e patch, c'era lo no release di SUDS a partire dallo 0.4 il 2010-09-15. Inoltre, la wiki e la roadmap sembrano un po 'trascurate.

Per me sembra che SUDS non venga più gestito.

Quindi, ecco le mie domande:

1. ha senso basare un progetto più ampio sulla schiuma come client SOAP?
2. C'è un fork di sud che implementa già alcune patch disponibili nel sistema di ticketing?
3. quali alternative sono disponibili, che hanno un ingombro di memoria inferiore e sono facili da usare e in grado di gestire complesse di grandi file WSDL

[aggiornamento novembre 2013] Sono passati

Più di due anni e si scopre che il progetto di suds originale è davvero morto. Non ci sono state ulteriori versioni dal 2010. A causa di questo, molte persone hanno iniziato a biforcarsi e le distribuzioni come Debian stanno distribuendo versioni con patch del pacchetto originale di suds per risolvere alcuni dei problemi.

Posso consigliare la forcella attivamente mantenuta da Jurko che ho usato con successo. Supporta python 3 e risolve molti dei problemi noti di suds. Note di rilascio e bug tracker sono disponibili su Bitbucket il pacchetto è disponibile anche su PyPI in modo che possa essere installato tramite pip.

Answer 1

Mentre non c'è uno standard certificato, se è necessario utilizzare SOAP, Suds è la scelta migliore. Suds può essere lento su WSDL di grandi dimensioni, e questo è qualcosa su cui stanno lavorando.

Nel frattempo, se non vi aspettate il vostro WSDL per cambiare spesso, si hanno due opzioni che possono acquistare un sacco di velocità:

1. Download tua WSDL a localhost
2. Utilizzando la cache

Download tua WSDL

Con gran parte del WSDL il problema è che prima si deve dow caricare ogni volta il WSDL, che può aggiungere un sovraccarico.Suds avrà il tempo di scaricare e analizzare l'intero WSDL all'avvio per assicurarsi che non sia cambiato.

Se è possibile scaricarlo sul sistema locale e quindi passarlo al costruttore Client utilizzando uno schema file:// nell'URL. Poiché Suds utilizza urllib2 per il trasporto HTTP, questo è perfettamente legittimo.

Ora, poiché non si fornisce un nome host nel proprio URL WSDL, sarà necessario passare anche un argomento location che specifica l'URL effettivo dell'applicazione SOAP.

Ecco un esempio:

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) 

Se siete interessati, ho usato questo metodo nel mio lavoro e hanno open sourced the code.

Caching tua WSDL

L'altra opzione è quella di utilizzare Suds' excellent caching feature. È necessario creare esplicitamente un oggetto cache e quindi passarlo al costruttore utilizzando l'argomento cache. Altrimenti, il valore predefinito è ObjectCache con una durata di 1 giorno.

Si potrebbe anche considerare l'utilizzo di entrambi questi approcci.

Answer 2

Un interessante up-to-date post può essere trovato qui: What SOAP client libraries exist for Python, and where is the documentation for them? Purtroppo, la libreria SOAP perfetta che si sta cercando non sembra esistere (ancora)

Answer 3

È il 2013. Questo è un aggiornamento per chiunque abbia riscontrato il problema con Python e SOAP come me.

Stavo cercando di usare SOAP in Python. Ho provato schiuma, ma purtroppo la libreria non è stato aggiornato dal 2010. Nella prima prova del mio codice, ho ricevuto questo errore:

RuntimeError: maximum recursion depth exceeded while calling a Python object 

che si rivela essere un problema schiuma ha con riferimenti ricorsivi sulle connessioni HTTPS. See drfence's answer. Ho dovuto correggere manualmente suds per superare il problema.

Sono passato a php. Non così semplice come Python, ma sono riuscito a farlo funzionare.

Answer 4

C'è un nuovo client SOAP ben gestito chiamato zeep. Supporta sia Python 2 che 3 e si basa su librerie lxml e richieste ben note.