MikeSchinkel
  • 0
Гуру

Подводные камни при распространении подключаемых модулей, которые обращаются к веб-службам SOAP?

  • 0

Мне интересно, с какими ловушками (если таковые имеются?) столкнулись разработчики здесь при распространении плагинов WordPress через репозиторий плагинов WordPress , в который встроен клиент SOAP для доступа к веб-службам SOAP для критически важных функций плагина (или любого плагина, широко распространяемого через любой другой репозиторий, в этом отношении.)

(Я предполагаю, что компания, публикующая плагины, будет намного лучше разрабатывать веб-сервисы RESTful, но я хочу подтвердить это мнение, опросив мнения других здесь. Обратите внимание, что я задал нашему собственному @EAMann связанный с этим вопрос о Namesake..ком.)

Я делаю это вики сообщества, чтобы мы могли фиксировать все мысли по этому вопросу.

Share
  1. У меня возникает соблазн закрыть это как «не настоящий вопрос» или «слишком локализованный», поскольку он был поднят некоторое время, и тишина может говорить о том, что это ловля ответов, которых просто не существует… По сути, использует SOAP API какие-либо отличия от любого другого API или аналогичной сетевой функциональности?.. Согласен/не согласен?

    • 0
    • @Rarst — API-интерфейсы SOAP и API-интерфейсы RESTful очень разные. SOAP — это очень сложный протокол на основе XML, который использует HTTP в качестве транспорта и продвигается крупными поставщиками со сложными инструментами для продажи (см. HTTP с дополнительными ограничениями. Это как разница между автомобильным двигателем и реактивным двигателем. Оба генерируют энергию, но каждый делает это по-разному.

      • 0
    • Естественно, я знаю, что между протоколами есть техническая разница. Однако существует ли специфичная для WP разница между «у моего плагина есть оболочка SOAP API где-то в углу» и «у моего плагина есть оболочка REST API где-то в углу»? Я чувствую, что это вопрос о жизнеспособности SOAP в целом, а не о его жизнеспособности в WordPress.

      • 0
    • @Rarst — плагины WordPress распространяются и будут работать во многих различных средах хостинга, поэтому они специфичны для широко распространенных проблем. Это также касается того, конфликтуют ли какие-либо стеки SOAP с ядром WordPress каким-либо образом.

      • 0
    • Это сетевое общение, так что не будет ли оно просто проходить через HTTP API? Он создан именно для того, чтобы абстрагировать код от особенностей хостинга и проблем совместимости.

      • 0
    • Спасибо за ваши комментарии. Я спрашивал о том, что кто-то создает только PHP SOAP-клиент для запуска в плагине WordPress для чужого.NET SOAP-сервера. Я даже не могу найти пример плагина, который делает это. И ваш опыт был тем, чего я опасаюсь.

      • 0
  2. Я не могу говорить конкретно о SOAP, но однажды я создал плагин (частный) для клиента, который должен был взаимодействовать с проприетарной сторонней веб-службой. В данном случае это был интерфейс без RESTful, который использовал сочетание строк запроса и XML-запросов POST для отправки запросов (в зависимости от сложности типа запроса) и возвращал данные результатов в XML.

    Я создал PHP-классы, чтобы помочь абстрагировать их службу в API, с которым мне было бы легче иметь дело, и сгладить несоответствия в их интерфейсе и различных типах XML-документов, которые они принимали и возвращали. Кроме того, создавая свою собственную абстракцию, я надеялся защитить свой код от будущих изменений с их стороны. Если бы они сохранили ту же базовую структуру для организации данных, но переключились на кодирование JSON, например, большая часть моей бизнес-логики осталась бы нетронутой, и мне нужно было бы только переписать части запроса и ответа для кодирования/декодирования данных.

    Хотя это и не относится к вашему вопросу, мой прошлый опыт работы с SOAP был в основном негативным. Уже давно ведутся споры о том, является ли SOAP сервисом RPC или средством передачи документов. Прибавьте к этому сложности, возникающие из-за слегка нестандартных реализаций (поищите, например, статьи об использовании модуля perl SOAP::Lite с сервером Microsoft SOAP), использования пространств имен XML и других факторов, и вы довольно быстро разочаруетесь.

    Интересно, однако, если ваш вопрос более конкретно связан с тем, что кто-то создает части SOAP как на стороне клиента, так и на стороне сервера? Если бы я создавал веб-сервис (и связанный плагин WordPress для доступа к нему), SOAP определенно не был бы моим первым выбором для API RPC или передачи данных.

    • 0
  3. Я лично думаю, что подключение к SOAP может быть болезненным, особенно если сервер Java, но я сделал это в специальном плагине, который разработал для клиента. В зависимости от ваших требований вам может не понадобиться встраивать специальный клиент SOAP, так как WordPress 3.2 отказался от поддержки PHP 4, а PHP 5 имеет встроенный клиент SOAP (ищите SoapClient на php.net). Просто убедитесь, что вы четко указали это в документации. что для этого требуется PHP 5. Если вы хотите поддерживать более старые версии PHP, это нормально, но единственная проблема, которую я вижу, это конфликты с именем вашей библиотеки.

    Например, я хочу использовать два плагина: один для сокращения URL-адресов, а другой для твиттера. Что ж, у плагина для укорачивания также есть некоторые функции для твиттера, и они оба включают одну и ту же библиотеку OAuth. Излишне говорить, что теперь я получаю ошибки о переопределении определенных классов OAuth.

    Обойти это в конечном итоге будут пространства имен PHP, но поскольку мы говорим о поддержке PHP 4, это не сработает. Лучше всего будет либо переименовать классы, чтобы библиотека SoapClient, например, теперь называлась MyPlugin_SoapClient, и использовать ее везде, либо вы можете просто обернуть свои операторы include следующим образом:

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

    И мы надеемся, что это решит любые конфликтные проблемы.

    • 0

Оставить ответ

You must login to add an answer.