Pièges lors de la distribution de plug-ins qui accèdent SOAP Services Web?
Je me demande quels pièges (le cas échéant?) Ici les développeurs ont rencontré lors de la distribution de plugins WordPress via le référentiel de plugins WordPress qui intègre un SOAP client pour accéder à SOAP services Web pour les fonctionnalités critiques du plugin (ou tout plugin distribué largement via un autre référentiel, par exemple) .)
(Je suppose qu'une entreprise publiant des plugins serait bien mieux de développer des services Web RESTful mais je souhaite valider cette opinion en sondant les opinions des autres utilisateurs. Notez que j'ai posé la question à notre propre @EAMann a question sur Namesake.com .)} _
Je fais de ce wiki une communauté afin que nous puissions capturer toutes les pensées sur le sujet.
Je ne peux pas parler spécifiquement de SOAP, mais j’ai construit un plugin (privé) pour un client qui devait communiquer avec un service Web tiers propriétaire. Dans ce cas, il s’agissait d’une interface non RESTful qui utilisait un mélange de chaînes de requête et de requêtes XML POST pour la soumission de requêtes (selon la complexité du type de requête), et renvoyait les données de résultat au format XML.
J'ai construit PHP classes pour aider à résumer leur service dans une API que je pourrais traiter plus facilement et pour aplanir les incohérences dans leur interface et les différents types de documents XML acceptés et retournés. De plus, en créant ma propre abstraction, j'espérais protéger mon code contre les modifications futures. S'ils conservaient la même structure de base pour l'organisation des données, mais passaient par exemple à un codage JSON, la plupart de ma logique métier resterait intacte et il me suffirait de réécrire mes éléments de demande et de réponse pour coder/décoder les données.
Bien que cela ne soit pas spécifique à votre question, mes expériences passées avec SOAP ont été principalement négatives. Il y a une longue bataille pour savoir si SOAP est un service RPC ou un transport de document. Ajoutez à cela des complications liées à des implémentations légèrement non standard (recherchez des articles sur l’utilisation du module SOAP :: Lite de Perl avec un serveur Microsoft SOAP, par exemple), l’utilisation d’espaces de nommage XML et d’autres facteurs. être frustré assez rapidement.
Je me demande toutefois si votre question concerne plus précisément le fait que quelqu'un crée à la fois les éléments SOAP côté client et côté serveur? Si je construisais un service Web (et le plugin WordPress associé pour y accéder), SOAP serait certainement non serait mon premier choix pour l’API RPC ou le transport de données.
Personnellement, je pense que la connexion à SOAP peut être difficile, en particulier si le serveur est Java, mais je l’ai fait dans un plug-in personnalisé que j'ai développé pour un client. En fonction de vos besoins, il se peut que vous n’ayez pas besoin d’incorporer un client spécial SOAP puisque WordPress 3.2 a cessé de prendre en charge PHP 4 et que PHP 5 a intégré SOAP client (recherche de SoapClient sur php.net) Assurez-vous simplement de préciser dans la documentation que cela nécessite PHP 5. Si vous souhaitez supporter les anciennes versions de PHP ça va, mais le seul piège que je vois, ce sont les conflits avec le nom de votre bibliothèque.
Par exemple, je veux utiliser deux plugins, un raccourci d'URL et un plugin Twitter. Eh bien, le plug-in de raccourcisseur possède également certaines fonctionnalités de Twitter et toutes deux incluent la même bibliothèque OAuth. Inutile de dire que je reçois maintenant des erreurs concernant la redéfinition de classes OAuth spécifiques.
Le moyen de contourner ce problème sera finalement PHP espaces de noms, mais puisque nous parlons de prendre en charge PHP 4, cela ne fonctionnera pas. Votre meilleur choix sera de renommer les classes pour que la bibliothèque SoapClient, par exemple, devienne maintenant MyPlugin_SoapClient et de l'utiliser partout, ou vous voudrez peut-être simplement envelopper vos instructions d'inclusion avec:
if (!class_exists('SoapClient')) { include 'inc/soapclient.php'; }
Et, espérons-le, cela résoudra tous les problèmes de conflit.