Osadzanie klienta SOAP we wtyczce WordPress?


16

Jaki jest najlepszy sposób na osadzenie klienta SOAP we wtyczce WordPress , którą można rozpowszechniać za pośrednictwem repozytorium wtyczek WordPress? Czy najlepiej używać?

Co więcej, dlaczego polecasz ten, który robisz? A jakie są zalety i wady każdego z nich. „Punkty bonusowe (karma)”, jeśli masz rzeczywiste doświadczenia z używaniem klienta SOAP w szeroko rozpowszechnionej wtyczce. Czy są jakieś różnice między wywoływaniem serwera .NET SOAP, serwera Java SOAP lub innego stosu serwerów SOAP?

Zauważ, że jest to powiązane pytanie z pytaniem „Pułapki związane z dystrybucją wtyczek uzyskujących dostęp do usług sieciowych SOAP?” i tworzę też wiki społeczności.

Aktualizacja

Oto kilka potencjalnie pomocnych linków dla innych badających to samo pytanie:

Odpowiedzi:


2

Abstrahuję od konkretnej biblioteki SOAP, abyś mógł później dodać obsługę większej liczby klientów. Podobnie jak w WP_Httpprzypadku serwera proxy dla wielu implementacji HTTP i wybiera w zależności od możliwości serwera.

Musiałem wcześniej grać z niektórymi bibliotekami, ale nie pamiętam, która z nich. Ogólnie wolę dołączać moduły PHP zamiast kodu zewnętrznego, ponieważ są one bardziej prawdopodobne, że będą aktualizowane i nie wymagają dodatkowego obciążenia (czasami trzeba załadować framework, aby użyć jednej jego części).

Dobrym pomysłem może być utworzenie odpowiedzi dla każdej biblioteki, abyśmy mogli dodać do niej zalety i wady. A może to bardziej ogólne pytanie lepiej pasuje do „prawdziwego” przepełnienia stosu?


Dziękuję za odpowiedź. Zgadzam się, że dobrze byłoby streścić, ale nie od razu. Myślę, że trzeba mieć spore doświadczenie w kilku bibliotekach, w przeciwnym razie ryzykuje się naruszeniem zasady YAGNI . Pytałem na StackOverflow, ale dyskutują w sposób abstrakcyjny i nie znają ograniczeń, które deweloperzy wtyczek WordPress powinni wziąć pod uwagę. BTW, nie ma tam większego zastosowania. Naprawdę chcę, aby wszyscy klienci rozpoznali, że proszą o problemy z usługami SOAP vs. RESTful.
MikeSchinkel 27.04. 11

@Mike: Rzeczywiście, istotną różnicą jest to, że dotyczy to twojej wtyczki, a nie interfejsu API, na którym inni będą rozszerzać? Wtedy rzeczywiście masz więcej swobody, aby później zmienić kod wewnętrzny i abstrakcję.
Jan Fabry
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.