HTTP GET binding may be used instead of SOAP binding to invoke running services. Unlike SOAP binding, HTTP GET encodes a query into a URI string. Two encoding styles are possible:

Complex types cannot be bound in either style. WSO2 SOA Enablement Server does not currently support the binding of arrays, although this is permitted in the http:urlEncoded style.

HTTP GET binding is most suitable when the Web service client is a web browser. Thanks to its simplicity, HTTP GET binding can be used from all types of web browsers and other clients compliant with the HTTP GET protocol. In addition, the response to an HTTP GET-bound message may be any mulitipart message.

In summary, the advantages of HTTP GET binding are:

The limitations of HTTP GET binding are:

	Note
	Only the client side of HTTP GET binding is supported in the current WSO2 SOA Enablement Server implementation.

	Note
	HTTP GET binding is not WS-I compliant. However, a WS-I compliant WSDL can include both compliant and non-compliant wsdl:binding elements.

Consider a client that is asking a shop to provide a price quote. In the query string, the name of the product, the amount of pieces and the product id is encoded. The URI string in the http:urlEncoded encoding style would be:

http://www.shop.address.com/QuoteService/ProductQuote?id=12345&name=SuperHigh% 20Boots&amount=4

Using the http:urlReplacement encoding style, the URI string would look like this:

http://www.shop.address.com/QuoteService/ProductQuote/12345/SuperHighBoots/4

If the client asks for a list of three different products, each with its own id and amount, the URI string might look like this:

http://www.shop.address.com/QuoteService/ProductQuote? id=12345&id=12346&id=12347&amount=4&amount=3&amount=7

The response message of the first two examples above would resemble:

<productPrice xmlns="http://www.shop.address.com/ProductQuote">
        <id>12345</id>
        <amount>4</amount>
        <pricePerUnit>200</pricePerUnit<
        <sale>10</sale>
        <totalPrice>720</totalPrice>
        <currency>USD</currency>
</productPrice>

The preceding XML snippet is a single part message. However, the response may be a multipart message as well. A WSDL file describing a service that returns such a response is in Example 102:

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
     xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
     xmlns:tns="http://www.shop.address.com/ProductQuote"
     targetNamespace="http://www.shop.address.com/ProductQuote"
     xsi:schemaLocation="http://schemas.xmlsoap.org/wsdl/ http://schemas.xmlsoap.org/wsdl/">

    <types>
        <xsd:schema>
            <xsd:element name="string" type="xsd:string"/>
            <xsd:complexType name="arrayOfStringType">
                <xsd:sequence>
                    <xsd:element name="arrayOfString" maxOccurs="unbounded" type="xsd:string"/>
                </xsd:sequence>
             </xsd:complexType>
        </xsd:schema>
        <xsd:schema>
            <xsd:complexType name="arrayOfIntType">
                <xsd:sequence>
                    <xsd:element name="arrayOfInt" maxOccurs="unbounded" type="xsd:int"/>
                </xsd:sequence>
            </xsd:complexType>
        </xsd:schema>
        <xsd:schema>
            <xsd:complexType name="productPriceType">
                <xsd:sequence>
                    <xsd:element name="oneItem" maxOccurs="unbounded">
                        <xsd:complexType>
                            <xsd:sequence>
                                <xsd:element name="id" type="xsd:string"/>
                                <xsd:element name="amount" type="xsd:int"/>
                                <xsd:element name="pricePerUnit" type="xsd:float"/>
                            </xsd:sequence>
                        </xsd:complexType>
                    </xsd:element>
                    <xsd:element name="sale" minOccurs="0" type="xsd:int"/>
                    <xsd:element name="totalPrice" type="xsd:float"/>
                    <xsd:element name="currency" type="xsd:string"/>
                </xsd:sequence>
            </xsd:complexType>
            <xsd:element name="productPrice" type="tns:productPriceType"/>
        </xsd:schema>
    </types>
    <message name="productQuoteInput">
        <part name="id" type="tns:arrayOfString"/>
        <part name="amount" type="tns:arrayOfInt"/>
    </message>
    <message name="productQuoteOutput">
        <part name="return" element="tns:productPrice"/>
    </message>
    <message name="productQuoteFault">
        <part name="reason" element="tns:string"/>
    </message>
    <portType name="productQuotePortType">
        <operation name="productQuote">
            <input message="tns:productQuoteInput"/>
            <output message="tns:productQuoteOutput"/>
            <fault name="productQuoteFault" message="tns:productQuoteFault"/>
        </operation>
    </portType>
    <binding name="productQuoteBinding" type="productQuotePortType">
        <http:binding verb="GET"/>
        <operation name="ProductQuote">
            <http:operation location="/ProductQuote"/>
            <input>
                <http:urlEncoded/>
            </input>
            <output>
                <mime:mimeXML/>
            </output>
            <fault name="productQuoteFault">
                <mime:mimeXML/>
            </fault>
        </operation>
    </binding>
</definitions>

Please note in Example 102 that the input part in the message declaration references a schema type while the output and fault parts reference a declared schema element.

Let us take a closer look at how WSO2 SOA Enablement Server processes queries when HTTP GET binding is used.

When a client invokes a service deployed on a server, the service parameters are first serialized into a special SAAJ message using a different namespace than the standard one. This allows the query to be processed at the XML/SOAP level in the standard way while distinguishing the HTTP GET protocol from the SOAP binding. Finally, the processed message is serialized to the URI string and sent to the server.

Let's look at an example. The code below shows a method signature with one in parameter (p0), one return value and one attachment (p1).

public String foo10(String p0, ResponseMessageAttachment p1);

When called, the following special SAAJ message is created:

<e:Envelope xmlns:d="http://www.w3.org/2001/XMLSchema"
                xmlns:e="http://systinet.com/wasp/protocol/get"
                xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
                xmlns:wn0="http://systinet.com/xsd/SchemaTypes/"
                xmlns:wn1="http://systinet.com/wsdl/runtime/invocation/httpget/src/"
                xmlns:wn2="http://systinet.com/wsdl/java/lang/">
    <e:Body>
        <p0 ns1:type="ns0:string" xmlns:ns0="http://www.w3.org/2001/XMLSchema"
                    xmlns:ns1="http://www.w3.org/2001/XMLSchema-instance">vlada</p0>
    </e:Body>
</e:Envelope>

Please note the different XML namespace used in the envelope. The value of the 'in' parameter has been serialized into the p0 element in the message body. To make the example complete, the following line contains the URI being transported to the server in the final stage of the method call.

http://localhost:6060/FooService/foo10?p0=vlada

The parameter value is now written immediately after the parameter name in the query part of the URI.

The incoming response is processed in a similar way, except in reverse. Strictly speaking, the response of a HTTP GET request may be data of any type stored into a single or multipart HTTP response message. To handle the response in the standard way, WSO2 SOA Enablement Server plays a few tricks. In case the first transport part is not XML, WSO2 SOA Enablement Server precedes this part with a fake one that is XML, making all the incoming parts attachments of the fake one. As described above, a special SAAJ message based on these parts is initialized; this message can then be processed at the XML/SOAP level. Finally, all message parts are deserialized into method parameters according to the client proxy method signature. The XML part is deserialized into the non-attachment parameters and the return value, while the rest is deserialized into the attachment parameters in the same order as in the method signature.

Receiving the signature of the method above, the response (in this case a multipart message) may look like this:

HTTP/1.0 200 OK
MIME-version: 1.0
Content-type: multipart/related; boundary=----------MULTIPART_BOUNDARY_f97a7693bd1----------;
type="text/xml"; start="<6513d75d45108e22-d5d221d5dc54a37e-9b32fb25fd8996cf-97f0a65d7386a2c0>"
Connection: close
Date: Mon, 15 Dec 2003 15:17:28 GMT
Server: WSO2 SOA Enablement Server for Java™/6.5.1 (Java/1.4.2; Windows XP/5.1)
Content-length: 561

------------MULTIPART_BOUNDARY_f97a7693bd1----------
content-type: text/xml
content-id: <6513d75d45108e22-d5d221d5dc54a37e-9b32fb25fd8996cf-97f0a65d7386a2c0>
<?xml version="1.0" encoding="utf-8"?>
<wn0:string_Response xmlns:wn0="http://systinet.com/xsd/SchemaTypes/"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
xmlns:d="http://www.w3.org/2001/XMLSchema"i:type="d:string">vlada</wn0:string_Response>

------------MULTIPART_BOUNDARY_f97a7693bd1----------
content-type: text/plain
vlada

------------MULTIPART_BOUNDARY_f97a7693bd1------------

If the status code of the response holds the INTERNAL ERROR value, the response is deserialized exactly the same as if it were a fault during a SOAP invocation.

For more information on this issue, please see the WSDL Specification.