nicht angemeldet
Webservice 2.0b
hi,
kommerzielle Lösungen setzen auf GPL, OpenSource und auf Empfehlungen. Anbieter von Webservices nutzen SOAP, XML u.a. mit allen Nachteilen, die damit verbunden sind (Overhead). Bei PayPal jedoch, habe ich eine interessante proprietäre Lösung für einen Webservice gefunden, die sogenannte NVP-API (was das ist, siehe dort).
Warum nicht noch einen kleinen Schritt weiter gehen? Vor ein paar Jahren bereits habe ich experimentell diesbezügliche Schritte unternommen, hier ist ein Beispiel, zum Testen freigegeben.
Vielleicht sollte auch ich mal eine Empfehlung abgeben ;)
Hotti
-
Hi,
kommerzielle Lösungen setzen auf GPL, OpenSource und auf Empfehlungen. Anbieter von Webservices nutzen SOAP, XML u.a. mit allen Nachteilen, die damit verbunden sind (Overhead). Bei PayPal jedoch, habe ich eine interessante proprietäre Lösung für einen Webservice gefunden, die sogenannte NVP-API (was das ist, siehe dort).
Warum nicht noch einen kleinen Schritt weiter gehen? Vor ein paar Jahren bereits habe ich experimentell diesbezügliche Schritte unternommen, hier ist ein Beispiel, zum Testen freigegeben.
Warum das Rad neu erfinden?
- Als Schnittstelle eine REST-API. Im Vergleich zu NVP hat es den Vorteil, dass die API sprechender ist und dadurch die Anfälligkeit für Fehlbenutzungen sinkt. Außerdem gibt es für die meisten Programmiersprachen Frameworks, die RESTful-Interfaces unterstützen.
- Wenn man Daten binär austauschen will, ein bestehendes Framework nutzen wie z.B. protobuf. Durch Code-Generatoren kann man gleich die Klassen erzeugen lassen, und das in verschiedenen Programmiersprachen.Bis die Tage,
Matti-
Anbieter von Webservices nutzen SOAP, XML u.a. mit allen Nachteilen, die damit verbunden sind (Overhead).
Wenn es nur um den Traffic geht, dieser lässt sich auch mit Komprimierungsverfahren wie gzip vermindern. Außerdem spielt die Wahl der Sprache eine wesentliche Rolle. JSON hat beispielsweise deutlich weniger Overhead als XML.
- Als Schnittstelle eine REST-API. Im Vergleich zu NVP hat es den Vorteil, dass die API sprechender ist und dadurch die Anfälligkeit für Fehlbenutzungen sinkt.
Sehe ich genauso.
-
hi,
Warum das Rad neu erfinden?
Du hast das Fettgedruckte nicht gelesen ;)
- Wenn man Daten binär austauschen will, ein bestehendes Framework nutzen wie z.B. protobuf.
Vergleiche das mal mit dem Serialize-Algorithmus, den ich in meinem Artikel beschreibe. Fällt Dir was auf? Richtig: Es geht auch anders, nämlich einfacher ;)
Keiner muss das Rad neu erfinden. Aber das Rad neu entdecken ist auch ein Abenteuer und zwar ein sehr Spannendes.
Schöne Grüße,
Hotti
-
-
hi,
für Interessierte gibt es einen weiteren Webservice bei mir.
Die API ist auf der Seite beschrieben.
Viel Spaß damit,
Horst