Fallstricke beim Verteilen von Plugins, die auf SOAP Web Services zugreifen?

Ich frage mich, welche Fallstricke (wenn überhaupt?) Entwickler beim Verteilen von WordPress-Plugins über das WordPress-Plugin-Repository , das einen SOAP-Client für den Zugriff auf SOAP-Web-Services für kritische Plugin-functionen einbetten (oder Plugins, die über ein anderes Repository verteilt werden) für diese Angelegenheit.)

(Ich gehe davon aus, dass ein Unternehmen, das Plugins veröffentlicht, viel besser daran wäre, REST-konforme Web-Services zu entwickeln , aber ich möchte diese Meinung bestätigen, indem ich hier die Meinung anderer prüfe . Beachten Sie, dass ich unsere eigene @EAMann- Frage zu Namesake gestellt habe .com .)

Ich mache dies zu einem Community-Wiki, damit wir alle Gedanken zu diesem Thema einfangen können.

Solutions Collecting From Web of "Fallstricke beim Verteilen von Plugins, die auf SOAP Web Services zugreifen?"

Ich kann nicht speziell mit SOAP sprechen, aber ich habe ein Plugin (privat) für einen Client erstellt, der einmal mit einem proprietären Webservice eines Drittanbieters kommunizieren musste. In diesem Fall handelte es sich um eine nicht REST-konforme Schnittstelle, die eine Mischung aus Querystrings und XML-POST-Anforderungen zum Übermitteln von Abfragen (abhängig von der Komplexität des Abfragetyps) und zurückgegebenen Ergebnisdaten in XML verwendete.

Ich habe PHP-classn erstellt, um den Dienst besser in eine API zu integrieren, mit der ich leichter umgehen konnte, und um die Inkonsistenzen in der Benutzeroberfläche und die verschiedenen Arten von XML-Dokumenten, die sie akzeptierten und zurückgaben, auszugleichen. Indem ich meine eigene Abstraktion erstellte, hoffte ich, meinen Code gegen zukünftige Änderungen an ihrem Ende zu schützen. Wenn sie die gleiche grundlegende Struktur zum Organisieren von Daten beibehalten würden, aber zum Beispiel zu einer JSON-Codierung wechseln würden, würde der Großteil meiner Geschäftslogik intakt bleiben, und ich würde nur meine Anfrage und Antwortstücke zum Codieren / Decodieren der Daten neu schreiben müssen.

Obwohl ich nicht speziell auf Ihre Frage eingegangen bin, waren meine bisherigen Erfahrungen mit SOAP meist negativ. Es hat einen langen Kampf darum gegeben, ob SOAP ein RPC-Dienst oder ein Dokumententransport ist. Kombinieren Sie dies mit Komplikationen, die sich aus leicht nicht standardisierten Implementierungen ergeben (suchen Sie nach Artikeln zur Verwendung des SOAP :: Lite-Moduls von Perl mit einem Microsoft SOAP-Server), verwenden Sie XML-Namespaces und andere Faktoren, und Sie werden ziemlich schnell frustriert sein.

Ich frage mich allerdings, ob Ihre Frage genauer gesagt in der Art ist, wie jemand sowohl die Client- als auch die Server-seitigen SOAP-Teile erstellt. Wenn ich einen Web-Service (und das zugehörige WordPress-Plugin für den Zugriff) aufbauen würde, wäre SOAP definitiv nicht meine erste Wahl für den API-RPC oder den Datentransport.

Ich persönlich denke, eine Verbindung zu SOAP kann ein Problem sein, besonders wenn der Server Java ist, aber ich habe es in einem benutzerdefinierten Plugin getan, das ich für einen Client entwickelt habe. Abhängig von Ihren Anforderungen müssen Sie möglicherweise keinen speziellen SOAP-Client einbetten, da WordPress 3.2 die Unterstützung für PHP 4 verworfen hat und PHP 5 einen eingebauten SOAP-Client hat (suchen Sie nach SoapClient auf php.net). Stellen Sie sicher, dass Sie es in der Dokumentation klarstellen dass es PHP 5 erfordert. Wenn Sie ältere Versionen von PHP unterstützen möchten, ist das kein Problem, aber der einzige Fehler, den ich sehe, sind Konflikte mit Ihrem Bibliotheksnamen.

Zum Beispiel möchte ich zwei Plugins verwenden, eines ist ein URL-Kürzler und eines ist ein Twitter-Plugin. Nun, das Shortener-Plugin hat auch einige Twitter-functionen und beide enthalten die gleiche OAuth-Bibliothek. Unnötig zu sagen, dass ich jetzt Fehler bei der Neudefinition bestimmter OAuth-classn bekomme.

Der Weg dazu wird vielleicht PHP Namespaces sein, aber da wir über die Unterstützung von PHP 4 sprechen, wird das nicht funktionieren. Am besten ist es, wenn Sie die classn umbenennen, so dass die Bibliothek SoapClient zum Beispiel jetzt MyPlugin_SoapClient ist und Sie diese überall verwenden, oder Sie möchten Ihre Include-statementen einfach mit folgenden Elementen umbrechen:

if (!class_exists('SoapClient')) { include 'inc/soapclient.php'; } 

Und das wird hoffentlich alle Konfliktprobleme lösen.