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.

The POST discussion

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).

Back to top

SOAP aligns to GET

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 Accept header to application/soap+xml to 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 Accept header. The client can set different content/type in Accept using the 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.

Back to top

Axis and WSDL support

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 method parameter and the other parameters.

For example, suppose I have implemented the order status service at the URL http://joker.psol.com/axis/order/Status.jws. The service has two methods, track and detailTrack, which take the order number (onumber) as a parameter. I can invoke the service through http://joker.psol.com/axis/order/Status.jws?method=track&onumber=56544322.

WSDL 2.0 (currently under development at the W3C) adds a pattern 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.

<operation name="track" pattern="http://www.w3.org/2003/11/wsdl/out-only">
   <output message="trackResponse"/>
</operation>

Back to top

Conclusion

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.

Resources

• 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, September 2003).
  
  
• 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 IBM Certified Developer in XML and related technologies.
  
  

About the author

Benoît Marchal is a Belgian consultant. He is the author of XML by Example, Second Edition and other XML books. He works mostly on XML, Java technology, and e-commerce. For more on this topic, see www.marchal.com.

Rate this article

Comments

Back to top

Table of contents

• The POST discussion
• SOAP aligns to GET
• Axis and WSDL support
• Conclusion
• Resources
• About the author
• Comments