Różnica między życzenie SoapClient i mydło curl zamówienie w php

Question

Jestem bardzo mylić z

Soap curl request znalazłem tutaj przykład SOAP request in PHP with CURL

i prośba Mydło użyciu SoapClient PHP http://php.net/manual/en/class.soapclient.php

Moje pytanie i wątpliwości są Po pierwsze - czy oba te elementy wypełniają ten sam cel.

Po drugie - czy występują różnice w wydajności, jeśli są one wykorzystywane do tego samego celu.

góry dzięki

Answer 1

Masz rację, że wypełniają one temu samemu celowi. Chociaż SoapClient ma wiele funkcji do obsługi wbudowanych żądań SOAP i gdzieś używa Curl.

Jak widać w dyskusji na temat SOAP z Curl programista tworzy kopertę SOAP, SoapClient może to zrobić dla ciebie. To samo dotyczy wykonywania wywołań metod.

W końcu dużo łatwiej jest używać SoapClient.

Answer 2

pierwsze pytanie: Szczerze, oni wypełnić tę samą niszę w koncepcji .. Nie może być czas, kiedy myślisz, że to „lepiej” do „print” xml po pewnej modyfikacji traktując go jako ciąg znaków, zamiast budować to i wyślij go poprzez mydło .. curl może zrobić więcej niż to, ale gdy zastosujemy go do kontekstu mydła, to SOAP potraktuje to żądanie jako "złożoną" całość, podczas gdy curl twoja wiadomość jest ciągiem prostym i prostym ..

Drugie pytanie: nie mogę podać żadnej konkretnej odpowiedzi. Wiem, że możesz wykonać kilka operacji wysyłania z curl, ale nigdy nie zauważyłem żadnego konkretnego wyniku wydajności, a ponadto istnieją pewne ramy, takie jak zebr a, która podkręca php curl dla (rzekomego) zwiększenia wydajności, chociaż nigdy ich nie próbowałem ... Ale ostatecznie curl zrobi niewiele więcej niż "wyślij" ciąg w przypadku mydlanego kręcenia soo wątpię, że może być jakaś szczególna degradacja wydajności ..

Answer 3

Spędziłem niezliczone godziny zajmując się SOAP w PHP. Teraz mogę stwierdzić, że znam to na wylot. :)

Pierwsze pytanie: SoapClient i cURL są przeznaczone do różnych celów. SoapClient to wszystko o SOAP, cURL to transport HTTP. Protokół dostępu SOAP jest o jeden poziom wyżej niż protokół transportowy. SOAP może być transmitowany przez dowolny wybrany przez ciebie transport: często dokument SOAP (który jest tylko zwykłym dokumentem XML) jest wysyłany przez SMTP (tj. Przez e-mail) w celu przechodzenia przez restrykcyjne ściany ogniowe. cURL jest tylko narzędziem do uzyskania dostępu do jakiegoś serwera WWW.

Drugie pytanie: Prędkość czasu spędzonego na lokalnej realizacji będzie minimalna w cURL. Ale będzie to negowane przez niską jakość takiego kodu, ponieważ nie będzie ono zgodne ze standardem SOAP i będzie musiało ulec uszkodzeniu w ten czy inny sposób (i może nawet nie powiadomić o tym). Zasadniczo w trakcie wykonywania większość czasu będzie wydawana na transport (tj. Na wolnej sieci/zajętym serwerze sieciowym), więc nie ma znaczenia, w którą stronę się posłużysz.

Zobaczmy teraz pod maską: rozszerzenie mydła w PHP jest dość niekompletne. Szybkie wyszukiwanie słowa "fikcja" daje 33 różnych lokalizacji w kodzie. Większość z nich php_encoding.c.Niestety PHP SOAP w niektórych przypadkach po prostu nie jest w stanie wyprodukować prawidłowego SOAP lub nie może zrozumieć właściwego SOAP - problemem jest interoperacyjność. Większość problemów jest między PHP a .NET SOAP, ale domyślam się, że jeśli spróbujesz uzyskać dostęp do .NET SOAP z cURL, będziesz potrzebował nieco więcej niż tylko kilka linii kodu, żeby to działało. Na szczęście zwykłe SOAP jest całkiem dobre w PHP SOAP i współpracuje z innymi implementacjami SOAP. Jeśli chcesz użyć SoapHeaders lub MustUnderstand, przygotuj się na trochę koszmaru. SoapHeaders są stosunkowo łatwe do zrobienia przy pomocy cURL. mustUnderstand będzie dość trudny do zrobienia w cURL.

Główną zaletą używania SoapClient jest WSDL (Web Service Description Language). W zasadzie można zrobić:

$client = new SoapClient("http://webserver.com/service.wsdl"); 
$client->executeRemoteFunction($paramters); 

z zwinięcie będziesz w stanie to zrobić, ponieważ nie ma WSDL parsera. Jeśli zdalny koniec zmieni swoje specyfikacje, implementacja cURL nie powiedzie się marnie i nie powiadomi cię. W tym momencie możesz powiedzieć: ale jeśli zdalny serwer WWW po cichu upuści executeRemoteFunction(), to też bym tego nie wiedział! Tak nie jest: SoapClient z wyjątkiem SoapFault throw i musisz go przechwycić i obsłużyć lub skrypt zostanie zatrzymany z nieobsługiwanym komunikatem wyjątku. Tak czy inaczej dowiesz się o tym.

Jednak nie oczekuj PHP SOAP, aby zrobić kilka dobrych rzeczy dla ciebie, takich jak sprawdzanie typu. Nawet gdyby zdalny plik WSDL wymagał xs: integer, to PHP SOAP zignoruje go i wyśle ​​dowolny typ, który podasz w milczeniu. Wpisz sprawdzanie za pomocą cURL? Nie można tego zrobić, ponieważ w ogóle nie ma obsługi WSDL.

Również podczas mówienia o SOAP WSDL należy pamiętać, że PHP będzie buforował WSDL przez 7 dni (ustawienie domyślne). Szybkie zmiany WSDL podczas programowania spowodują problemy w krótkim czasie: czyszczenie pamięci podręcznej WSDL nie zawsze jest łatwe. Ale z drugiej strony możesz całkowicie wyłączyć pamięć podręczną WSDL podczas programowania: prędkość spadnie, ale przynajmniej będziesz mógł się rozwijać bez "Nie mam pojęcia, dlaczego nie robi tego, co chcę!"

Czytając o kilku dobrych rzeczach w PHP SOAP, możesz się zastanawiać, czy istnieje jakikolwiek dobry powód, by używać cURL do SOAP. A moja odpowiedź brzmi "tak", jest. Niestety PHP SOAP nie jest w stanie utworzyć niektórych typów SoapHeader. Więc jeśli przejdziesz do tak zaawansowanych rzeczy, będziesz musiał użyć SoapClient, aby utworzyć dokument SOAP, a następnie zmodyfikować go za pomocą niektórych narzędzi XML (takich jak PHP DOM), a następnie wysłać za pomocą cURL. Ale to zupełnie inna historia.

Jeśli zaczynasz od SOAP w PHP, zrób sobie przysługę i trzymaj się rozszerzenia PHP SOAP, a nie cURL. Jest to czystszy sposób radzenia sobie z SOAP, jest szybki, rozszerzenie jest utrzymywane (więc oczekiwać, że jego interoperacyjność wzrośnie w końcu), rozumie WSDL i zapewnia dobre raportowanie błędów i obsługę.