SOAP version 1.2

6.Use SOAP in HTTP

This section describes how to coordinate SOAP with HTTP When HTTP Extension Framework is used or not used. Binding SOAP to HTTP can use the rich feature set of HTTP to provide the advantages of using the SOAP method and distribution adaptability. The transmission of SOAP over HTTP does not mean that SOAP can completely surpass the semantics of HTTP. A more appropriate description should be that the semantics of SOAP naturally become the semantics of HTTP through HTTP ing.

SOAP naturally uses the HTTP Request/Response Message model to place the parameters of the SOAP request in the HTTP request, and the parameters of the SOAP response in the HTTP response. Note: In any case, the intermediary between SOAP and HTTP is different. That is to say, the HTTP intermediainfo address based on the HTTP Connection header field cannot process the SOAP entity in the HTTP request.

When a SOAP message body needs to be included in an HTTP message, the HTTP application must comply with RFC2376[3]Use the media type "text/xml ".

6.1 Soap http Request

Although SOAP can be used together with multiple HTTP request methods, the binding here only defines how SOAP is transmitted in HTTP Post requests. (SeeSection 7Learn how to use SOAP in RPC andSection 6.3How to use HTTP Extension Framework)

6.1.1 SOAPAction field in HTTP Header

The SOAPAction HTTP request header field can be used to indicate the purpose of a soap http request. Its value is a URI that identifies the destination. SOAP has no strict restrictions on the format. At the same time, there are no strict restrictions on the description of the URI and whether it can be parsed. When a soap http request is sent, the HTTP client must use this header field.

Soapaction	=	"SOAPAction": "[<"> URI-reference <">]
URI-reference	=	<As defined in RFC 2396[4]>

The existence of the SOAPAction header field and its content can be used by the server, such as the firewall, to filter SOAP request messages in HTTP. When the value of this field is a null string (""), it means that the purpose of the SOAP message is provided by HTTP Request-URI. If there is no value, it indicates there is no indication for the purpose of the message.

For example:

Example 42

SOAPAction: "http://electrocommerce.org/abc#MyMessage"SOAPAction: "myapp.sdl"SOAPAction: ""SOAPAction:

Examples of values for SOAPAction6.2 Soap http Response

SOAP on HTTP follows the semantics of the HTTP status code that represents the communication status in HTTP. For example, the 2xx Status Code indicates that the request containing the SOAP component on the client is successfully received, understood, and accepted.

When a SOAP error occurs during request processing, the soap http Server must send an HTTP 500 "Internal Server Error" response and contain a SOAP Fault Element in the SOAP message containing the response (seeSection 4.4.

6.3 HTTP extension framework

SOAP messages can be used with HTTP Extension Framework[6]Used together to identify the appearance and intent of a soap http request.

Whether to use Extension Framework or simple HTTP is a policy and capability issue for communication parties. The client can forcibly use HTTP Extension Framwork through a forced Extension declaration and a "M-" HTTP method name prefix. The server can use the 510 "Not Extended" HTTP status code to force the HTTP Extension Framework. That is to say, through an additional round trip, each communication party can detect other communication parties and such actions.

The Extension identifier used to identify SOAP using the Extension Framework is:

http://www.w3.org/2001/06/soap-envelope

6.4 Soap http exampleExample 43

POST /StockQuote HTTP/1.1Content-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "http://electrocommerce.org/abc#MyMessage"<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > . . .</env:Envelope>

Soap http Request Using POST

　

Example 44

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: nnnn<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > . . .</env:Envelope>

Soap http Response to Example 43

　

Example 45

M-POST /StockQuote HTTP/1.1Man: "http://www.w3.org/2001/06/soap-envelope"; ns=NNNNContent-Type: text/xml; charset="utf-8"Content-Length: nnnnNNNN-SOAPAction: "http://electrocommerce.org/abc#MyMessage"<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > . . .</env:Envelope>

Soap http Request using the experimental HTTP Extension Framework

　

Example 46

HTTP/1.1 200 OKExt:Content-Type: text/xml; charset="utf-8"Content-Length: nnnn<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" > . . .</env:Envelope>

Soap http Response to Example 457. Use SOAP in RPC

One design goal of SOAP is to use XML scalability and scalability to encapsulate and exchange RPC calls. This section defines a unified representation of remote process calls and responses.

In fact, we can also anticipate that the representation in the RPC environment may be combined with the encoding style defined in other representations. SOAP encodingStyle attributes (seeSection 4.3.2) Can be used to specify the encoding style of the method call/response used in this section.

Bind SOAP to the SOAP protocol in RPC (seeSection 6) Is orthogonal. When HTTP is used as the media for binding the SOAP protocol, an RPC call can be mapped to an HTTP request, while an RPC response can be mapped to an HTTP response. In any case, RPC using SOAP is not limited to HTTP binding.

To implement a method call, the following information is required:

• URI of the target SOAP Node

• Method Name

• Optional features of methods or processes

• Parameters of a method or process

• Optional header data

SOAP relies on Protocol binding to provide a mechanism for transmitting Uris. For example, for HTTP, the request URI specifies the resource corresponding to the call. Except that the URI is required to be valid, SOAP has no restrictions on this address (see[4]To obtain more information about the URI ).

7.1 RPC and SOAP Body

Both RPC call and response are in the SOAP Body element (seeSection 4.3), Using the following representation:

• A method call is modeled into a structure struct.

• The call to this method is displayed as a simple structure struct that contains an access identifier for each [in] or [in/out] parameter. The name and type of the structure can be identified by the name of the process or method.

• Each [in] or [in/out] parameter is represented as an access identity. The name and type of the access identity correspond to the name and type of the corresponding parameter. Their order is also in the order of the original RPC.

• A Method response is modeled into a structure struct.

• The response of this method is displayed as a simple structure struct that contains an access identifier for each [out] or [in/out] parameter. The first access identifier is the return value, followed by the return parameters in the original order.

• Each [out] or [in/out] parameter is represented as an access ID. The name and type of the access ID correspond to the name and type of the corresponding parameter. The access identifier name of the returned value does not have much semantics. Similarly, the structure name does not have much semantics. Of course, in any case, after the method name of the "Response" string is added, there must be a convention to name it.

• When a method call error occurs, the SOAP Fault element should be used for encoding (CateringSection 4.4). If a binding protocol has additional rules for error expressions, these rules should be observed.

As previously stated, the structure of methods and responses can be used inSection 5You can also use other encodings described in the encodingStyle attribute (seeSection 4.1.1).

The application can handle the request for missing write parameters, but it can return an error.

If "result" is included in the response, the response is successful. If "fault" is included, the response fails. Therefore, if the method response contains both "result" and "fau ",