XML oder SOAP für ebay-API?
Andreas Bruhn
im Betreff steht eigentlich ja schon alles wichtige. Die ebay-API
bietet laut Doku zwei Zug�nge an: einmal �ber XML oder �ber SOAP
Was empfehlen diejenigen die sich schon mit der ebay-API (und Doku
usw.) besch�ftigt haben?
Instinktiv w�rde ich ja XML nehmen, weil meine ersten und bisher
einzigen Erfahrungen mit SOAP unter Python eher negativ waren. Aber
das war auch Anfang 2004 gewesen und seitdem kann sich ja doch das
eine oder andere zum besseren entwickelt haben.
Gr��e,
Andreas
Stefan Behnel
> im Betreff steht eigentlich ja schon alles wichtige.
SOAP *ist* XML, also macht die ï¿œberschrift eigentlich gar keinen Sinn.
Wahrscheinlich meinst du XML-RPC?
Stefan
Diez B. Roggisch
SOAP ist Mist. Richtig grosser. Nicht nur in Python, sondern generell.
Nimm die andere API.
Diez
Stefan Behnel
> SOAP ist Mist. Richtig grosser. Nicht nur in Python, sondern generell.
Immer wieder gern zitierter Artikel in diesem Zusammenhang:
http://www.wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/
Stefan
Diez B. Roggisch
Ja, ich hab's mir ausnahmsweise mal verkniffen - aber den bittersuessen
Freudenschmerz beim lesen habe ich aus zu viel mieser SOAP-Erfahrung...
Diez
Andreas Bruhn
> Andreas Bruhn schrieb:
[...]
>>
>> Instinktiv w�rde ich ja XML nehmen, weil meine ersten und bisher
>> einzigen Erfahrungen mit SOAP unter Python eher negativ waren. Aber
>> das war auch Anfang 2004 gewesen und seitdem kann sich ja doch das
>> eine oder andere zum besseren entwickelt haben.
>
> SOAP ist Mist. Richtig grosser. Nicht nur in Python, sondern generell.
> Nimm die andere API.
Werde ich machen. Ich habe jetzt auch auf irgendeiner der
ebay-Developer-Seiten gelesen dass ich bei SOAP immer nur SOAP zur�ck
bekomme, w�hrend ich bei XML-Anfragen angeben kann ob ich die Antwort
als XML, JSON, NV [Name-Value] zur�ckbek�mmen m�chte.
Ich meine mich zu erinnern dass ich auch mal innerhalb der letzten 12
Monate mal ganz kurz wieder mit SOAP herumgespielt hatte:
irgendwann/irgendwo mal solch eine WSDL-Definitionsdatei eingelesen
und hinten dann mehr oder weniger (eher weniger) benutzbaren Code raus
bekommen.
Ich f�rchte ja, wenn ich die WSDL-Beschreibung z.B. der Trading-API
durchlaufen lasse, bekomme ich mindestens eine Monsterklasse die
Methoden f�r alle(!) API-Funktionen enth�lt. :-(
Da baue ich mir doch lieber selbst eine kleine Klasse zusammen die
dann nur 3-4 Methoden, f�r nur genau die API-Aufrufe die ich auch
brauche, enth�lt.
Gr��e,
Andreas
Andreas Bruhn
> Andreas Bruhn, 19.11.2009 19:32:
>> im Betreff steht eigentlich ja schon alles wichtige.
>
> SOAP *ist* XML, also macht die �berschrift eigentlich gar keinen Sinn.
> Wahrscheinlich meinst du XML-RPC?
Naja, XML-RPC ist, ebenso wie SOAP, auch XML. Macht die Unterscheidung
also eigentlich Sinn?
Aber zur�ck zum Thema: Ich halte mich da an
http://pages.ebay.de/entwickler/api.html
und an
http://pages.ebay.de/entwickler/sdk.html
Auf den englischsprachigen Seiten habe ich solche Grafiken jetzt
leider nicht gefunden. Aber diese Grafiken auf den deutschen Seiten
sind wohl etwas �lter. Die REST-API scheint sich k�rzlich zugunsten
der Shopping-API aufgel�st zu haben.
F�r mich unterscheidet sich das Ganze zwischen
a.) aufgebl�hte XML-Dateien per "einfachen" SOAP-Methodenaufruf an die
ebay-Server schicken
oder
b.) schlanke XML-Dateien (die nicht der XML-RPC Spezifikation
entsprechen) per "Hand" erzeugen und an die ebay-Server schicken.
Gr��e,
Andreas
Rainer Grimm
> SOAP ist Mist. Richtig grosser. Nicht nur in Python, sondern generell.
du angeschaut.
Ich denke, für Python und ZSI hast du recht. Da bewegt sich gar nichts
mehr über die Kernfunktionalität hinaus. Wir verwendeten letztendlich
die C++ Implementierung gsoap. Die ist sehr performant, erlaubt
Streaming grosser Daten ( > 1.GByte) und lässt sich in SSL kapseln.
Das Projekt ist sehr gut gepflegt und unterstützt im grossen und
ganzen auch die Soap Security und Proxy Konzepte. Gegen den Server
liesen wir testweise Clients in Java und Python (ZSI) laufen, nur um
zu testen, ob es prinzipiell tut. Alles ging auf Anhieb.Für unseren
Anwendungsfall, als internes Kommunikationsprotokoll unserer Client -
Server Arichtektur mit mehr als 1000 Clients, passt es. Darüber hinaus
besitzen wir die Möglichkeit, sprachübergreifend Clients zu schreiben,
die die selbe Netzwerksprache sprechen.
Tschüs Rainer
Diez B. Roggisch
> Am Fri, 20 Nov 2009 08:47:45 +0100 schrieb Stefan Behnel:
>
>> Andreas Bruhn, 19.11.2009 19:32:
>>> im Betreff steht eigentlich ja schon alles wichtige.
>> Wahrscheinlich meinst du XML-RPC?
>
> Naja, XML-RPC ist, ebenso wie SOAP, auch XML. Macht die Unterscheidung
> also eigentlich Sinn?
HTTP und CORBA sind auch nur irgendwie Bytes die ueber eine Datenleitung
gehen. Trotzdem *sehr* unterschiedlich.
> Aber zur锟絚k zum Thema: Ich halte mich da an
>
> http://pages.ebay.de/entwickler/api.html
>
> und an
>
> http://pages.ebay.de/entwickler/sdk.html
>
> Auf den englischsprachigen Seiten habe ich solche Grafiken jetzt
> leider nicht gefunden. Aber diese Grafiken auf den deutschen Seiten
> sind wohl etwas 锟絣ter. Die REST-API scheint sich k锟絩zlich zugunsten
> der Shopping-API aufgel锟絪t zu haben.
>
> F锟絩 mich unterscheidet sich das Ganze zwischen
>
> a.) aufgebl锟絟te XML-Dateien per "einfachen" SOAP-Methodenaufruf an die
> ebay-Server schicken
>
> oder
>
> b.) schlanke XML-Dateien (die nicht der XML-RPC Spezifikation
> entsprechen) per "Hand" erzeugen und an die ebay-Server schicken.
Mir ist nicht ganz klar, wie klar dir ist was ein "einfacher"
SOAP-Aufruf ist.
Das SOAP bloated ist - geschenkt. Das Problem ist, dass der "einfache"
Aufruf sich sehr kompliziert gestalten kann, je nach dem was da an
Datentypen ueber die Leitung geht. Und das Interoperabilitaet zwischen
SOAP-Stacks schlecht ist.
Mit der Konsquenz, dass wir zB fuer eine .NET-Service-Anbindung den
SOAP-Datenverkehr (mit einem .NET-client) mitgeschnitten haben, und dann
das XML in Form von Genshi-templates dynamisiert.
Also letzlich von Hand erzeugte XML-Dokumente, die man aber niemals
erzeugt bekommen haette ohne funktionierenden Client, weil die Spec so
schlecht ist.
Diez
Diez B. Roggisch
> Hallo,
>> SOAP ist Mist. Richtig grosser. Nicht nur in Python, sondern generell.
> Wie kommst du zu dieser Aussage? Welche soap Implemtentierungen hast
> du angeschaut.
Apache Axis, .NET, ZSI, SOAPPy.
> Ich denke, f�r Python und ZSI hast du recht. Da bewegt sich gar nichts
> mehr �ber die Kernfunktionalit�t hinaus. Wir verwendeten letztendlich
> die C++ Implementierung gsoap. Die ist sehr performant, erlaubt
> Streaming grosser Daten ( > 1.GByte) und l�sst sich in SSL kapseln.
> Das Projekt ist sehr gut gepflegt und unterst�tzt im grossen und
> ganzen auch die Soap Security und Proxy Konzepte. Gegen den Server
> liesen wir testweise Clients in Java und Python (ZSI) laufen, nur um
> zu testen, ob es prinzipiell tut. Alles ging auf Anhieb.F�r unseren
> Anwendungsfall, als internes Kommunikationsprotokoll unserer Client -
> Server Arichtektur mit mehr als 1000 Clients, passt es. Dar�ber hinaus
> besitzen wir die M�glichkeit, sprach�bergreifend Clients zu schreiben,
> die die selbe Netzwerksprache sprechen.
Ich habe bisher noch nichts in SOAP gesehen, dass ich mit XMLRPC nicht
auch hinbekommen haette. Denn in dem Moment, wo zB die Apache Axis
Bindungen fuer Java collections-Typen ins Spiel kommen, ist es dahin mit
der Interoperabilitaet. Dann muss man muehselig von Hand die Aufrufe
zurechtfummeln usw.
Von fehlenden Elementen der Spezifikation ueber Dinge wie
Session-informationen usw mal ganz zu schweigen.
Das die Python-spezifische Situation *nochmal* schlimmer ist, kommt noch
oben drauf. Mit wsdl2py generierte Klassen hatten eklatante Fehler, die
man dann per hand hat korrigieren muessen. Nur um dann fuer einen Aufruf
eine absurde Objektierarchie aufbauen zu muessen, und das Ergebnis ist
natuerilch auch wieder so ein Monster. Nix simpler Funktionscall.
Am Ende des Tages habe ich mehr Aufwand als bei XMLRPC, aber noch
*lange* nicht die Faehigkeiten (OO, Callbacks, kompaktes
Binaerprotokoll, Life-cycle-management usw) von CORBA.
Summa summarum haelt SOAP einfach nicht, was es verspricht - weder ist
es simpel, noch objekt-basiert, und interoperabel nur in Grenzen. Da
sind andere Protokolle *viel* weiter.
MfG Diez
Marek Kubica
"Diez B. Roggisch" <de...@nospam.web.de> wrote:
> Das die Python-spezifische Situation *nochmal* schlimmer ist, kommt
> noch oben drauf. Mit wsdl2py generierte Klassen hatten eklatante
> Fehler, die man dann per hand hat korrigieren muessen.
Ich bin jetzt auch weit davon entfernt SOAP zu empfehlen oder gar zu
mögen, aber "suds" braucht kein wsdl2py was die ganze Sache viel
angenehmer macht.
(Wobei ich XML-RPC Introspection auch irgendwie problemloser als WSDL
finde)
grüße,
Marek
Andreas Bruhn
> Andreas Bruhn schrieb:
>> Am Fri, 20 Nov 2009 08:47:45 +0100 schrieb Stefan Behnel:
>>
>>> Andreas Bruhn, 19.11.2009 19:32:
>>>> im Betreff steht eigentlich ja schon alles wichtige.
>>> SOAP *ist* XML, also macht die �berschrift eigentlich gar keinen Sinn.
>>> Wahrscheinlich meinst du XML-RPC?
>>
>> Naja, XML-RPC ist, ebenso wie SOAP, auch XML. Macht die Unterscheidung
>> also eigentlich Sinn?
>
> HTTP und CORBA sind auch nur irgendwie Bytes die ueber eine Datenleitung
> gehen. Trotzdem *sehr* unterschiedlich.
War auch eher rhetorisch gemeint, die Frage. Das XML der ebay-API
unterscheidet sich ja auch von dem XML f�r ein XML-RPC Aufruf.
[...]
>>
>> F�r mich unterscheidet sich das Ganze zwischen
>>
>> a.) aufgebl�hte XML-Dateien per "einfachen" SOAP-Methodenaufruf an die
>> ebay-Server schicken
>>
>> oder
>>
>> b.) schlanke XML-Dateien (die nicht der XML-RPC Spezifikation
>> entsprechen) per "Hand" erzeugen und an die ebay-Server schicken.
>
> Mir ist nicht ganz klar, wie klar dir ist was ein "einfacher"
> SOAP-Aufruf ist.
So einfach dass das Wort 'einfach' in Anf�hrungszeichen geh�rt. ;-)
Theoretischer Ablauf: die WSDL-Beschreibung durch z.b. wsdl2py jagen
und schon hat man einen verdammt gro�en Haufen Klassen und Methoden
die man "nur" noch geeignet aufrufen muss damit man kurze Zeit sp�ter
ein Response-Objekt mit der Antwort vom Server in der Hand h�lt.
Aber nach deinen Ausf�hrungen weiter unten im Thread scheint ja immer
noch ein Unterschied zwischen der Theorie und der Praxis (insbesondere
bei Python) zu bestehen.
Ich habe jetzt auch meinen letzten Versuch mit SOAP wiedergefunden.
Vor einigen Jahren hatte ich mal ernsthaft versucht eine
SOAP-Kommunikation mit Python aufzubauen, aber jetzt im September
hatte ich wohl ZSI f�r mich entdeckt und dann erstmal nur die
Amazon-WSDL-Beschreibung durch wsdl2py gejagt.
Schon hatte ich ein paar hundert Klassen .... ;-( zwar automatisch
erstellt, aber alle mehr oder weniger merkw�rdig aufgebaut.
Da bleibe ich dann lieber bei der XML-API von ebay. Da hoffe ich dann
das die Spec wenigstens halb so gut ist wie sie umfangreich ist und
baue mir meine Klassen selbst zusammen.
Da muss ich mich zwar dann auch noch mit dem parsen und zusammenbauen
von XLM-Dateien besch�ftigen, aber ich habe am Ende nur die Klassen
die auch wirklich brauche und ich kenne den Code wenigsten gut.
Gr��e,
Andreas