Since the publishing of SOAP 1.0, a number of people have complained about its reliance on the HTTP POST method. Many felt that SOAP utilized a popular protocol (HTTP) but showed little respect and understanding for the architecture it was built upon.
The 1.2 release, developed under the auspices of the W3C, addressed this issue. The W3C has invested a great deal of effort in abstracting many aspects of the protocol so that it can be more easily deployed across a broad range of technologies. The rewriting enables SOAP 1.2 to support SMTP in addition to HTTP, and to make better use of HTTP.
What is the problem with POST? In a nutshell, HTTP defines different methods for interacting with a server, the primary ones being GET and POST. In practice, GET is appropriate for most requests while POST is reserved for forms that update the site. According to the HTTP specification, GET is intended for information retrieval and should be safe and idempotent.
Safe in this context means that the operation is intended to retrieve, not modify, the information. In other words, a GET request should generally be free from side-effects. Idempotent means that several requests to the same URL will return the same result. The complete definitions are less stringent than it seems. Essentially, the goal is that when a user follows a link, she can be confident that she is not modifying the resource from her standpoint.
For example, the front page of a news site is updated continuously. Although a second request will return a different batch of news, the operation is still considered safe and idempotent because it always returns the current news. Likewise counters are OK.
A POST request should not be taken so lightly. POST identifies requests that may modify resources on the server. To continue with the news site example, reader comments on an article should be implemented through a POST request because the site is different after the comment has been posted (if, for example, a new comment appears below the article).
The difference between GET and POST is not always so rigid and some areas are gray . Many sites encapsulate simple information retrieval in a POST request, possibly because the developer thought it would make his life simpler.
While the discussion on HTTP methods may sound abstract and theoretical, it is not. The browser and intermediary software (proxies, firewalls, and content delivery solution à la Akamai) depend on the ability to differentiate between requests for optimal performances (see Resources).
SOAP originally supported POST requests only. Yet Web services may implement services that are safe as defined above. For example, a service that inquires about the progress of an order is both safe and idempotent. According to the HTTP specification, it should be implemented as a GET request. According to SOAP 1.0, it must be a POST.
SOAP 1.2 introduces Message Exchange Patterns (MEPs) and a new HTTP binding. By combining the two, you can finally implement a Web service that replies to GET requests. MEPs document the interaction patterns between the client and the server. The SOAP Request-Response MEP is a typical Web service interaction: The client sends a request to the server, and the server replies.
Here, I will look at the SOAP Response MEP more closely. This MEP defines a response only, with no request. In practice, this means that a request has been sent but it is not a SOAP request -- only the response is SOAP. When combined with the new HTTP binding, the Response MEP enables GET requests. Here's how it works:
- The client issues a GET request. It sets the
application/soap+xmlto request a SOAP answer.
- The server replies and the client processes the response as a regular SOAP response.
The server differentiates SOAP
requests from regular HTML requests through the
header. The client can set different content/type in
q property to indicate its preferences.
Depending on the needs of the service, the client may
include parameters in the URL through the usual URL encoding methods
(typically after a
? character). For example, a
service that reports on the status of a server farm may not need any
parameters. By definition, it returns the status of the current server.
Conversely, a service that reports on a product's availability and price will
take the product identifier (or name) as a parameter.
By now, you may be wondering how the client knows which URL to call and which parameter to pass, since the request is not part of SOAP. The answer is simple: The SOAP server should do what regular Web servers do and include the URL in a previous SOAP interaction. Nothing prevents mixing and matching GET and POST.
As an example, imagine a service that processes orders of office items (pens, paper, scissors, and the like). The service accepts an order through SOAP; obviously such an order request is neither safe nor idempotent, so it is sent as a POST. The response from the server may include a URL to track the order's progress. Tracking is safe and idempotent, so it's best implemented through GET.
At the time of writing, Axis supports SOAP
1.1 only, but still implements a limited form of GET. You can invoke any
request through its URL, followed by a
parameter and the other parameters.
For example, suppose I have
implemented the order status service at the URL
The service has two methods,
detailTrack, which take the order number (
onumber) as a parameter. I can invoke the service
WSDL 2.0 (currently under development at the W3C) adds a
attribute to operation definitions. This attribute indicates which SOAP
MEPs a service supports (WSDL calls MEP patterns so there's no
confusion between SOAP and WSDL). For example, the tracking service may be
defined as in Listing 1.
Listing 1. WSDL excerpt
<operation name="track" pattern="http://www.w3.org/2003/11/wsdl/out-only"> <output message="trackResponse"/> </operation>
The simple principles behind the Web have proven their scalability and reliance. It is a very positive development that SOAP, one of the major standards underlying Web services, has taken steps to align more closely with this incredibly successful architecture.
While you wait for your favourite kits to be upgraded to SOAP 1.2 and WSDL 2.0, review your Web services and identify the safe operations that are prime candidates for migrating to the GET binding.
- Participate in the discussion forum for Benoît Marchal's Working XML column.
- See how the W3C is working to bring WSDL 2.0 up to speed with
the enhancements in SOAP 1.2.
- Learn more about SOAP at the W3C's
XML Protocol Working Group page.
- While you're at it, check out what the W3C has to say about HTTP.
- Visit Brian D. Davison's Web Caching and Content Delivery Resources for lots of useful information on caching, proxies, and content delivery.
- In "When
to use GET?" Leigh Dodds chronicles the discussion on adding GET
support to SOAP within the W3C.
- Read Russell Butek's tip "Send
and receive SOAP messages with JAX-RPC" (developerWorks,
IBM trial software: Build your next development project with trial software available for download directly from developerWorks.
- Find more XML resources on the developerWorks XML zone. For a complete list of XML tips to date, check out the tips summary page.
- Sign up for the weekly Web services/XML tips newsletter from developerWorks.
- Find out how you can become an
Certified Developer in XML and related technologies.