meng-tian / php-soap-interpreter Goto Github PK

option features rather than feature in comment and readme.

Some SOAP servers answers in mime-boundary format. It is ok for SOAP generally, but php's soap client don't understand this. I didn't see a good way to solve this, but here is a working one.

Like SoapClient::::__soapCall, Interpreter::response may need to accept output header by reference, and return the SOAP response headers.

I want send soap request.
The xml demo like this, how can i generate the request

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v2="http://www.huawei.com.cn/schema/common/v2_1" xmlns:loc="http://www.csapi.org/schema/parlayx/sms/send/v2_2/local">
   <soapenv:Header>
      <v2:RequestSOAPHeader>
         <v2:spId>50000001</v2:spId>
    <v2:spPassword>xxxxxxx</v2:spPassword>
    <v2:serviceId>1</v2:serviceId>
      </v2:RequestSOAPHeader>
   </soapenv:Header>
   <soapenv:Body>
      <loc:sendSms>
         <loc:addresses>tel:13512345678</loc:addresses>
         <loc:message>123</loc:message>
      <loc:priority>5</loc:priority>
      </loc:sendSms>
   </soapenv:Body>
</soapenv:Envelope>

thanks

Some function args may worth to add type declarations, e.g., Interpreter::request's arguments and options are array.

In order to use Interpreter::response without firstly calling Interpreter::request in wsdl mode, Interpreter or Soap should be able to find an available function name and its required args. With a function name and its args, it will be safely to use __soapCall to interpret the given response string, otherwise wsdl mode may complain your function name is not valid.

The reason of not taking advantage of non-wsdl mode is because the interpreted results of wsdl and non-wsdl mode are different. Additionally, when an Interpreter is instantiated in wsdl mode, it shouldn't silently interpret the given response in a non-wsdl manner.

1. add license info
2. add usage example