Tip: SOAP 1.2 and the GET request

A first look at the Response MEP

SOAP 1.2 brings changes that help to weave Web services more into the fabric of the Internet. One of these changes is the introduction of the GET method. GET is important because it enables various optimizations. This has been demonstrated by the Web itself, which uses GET extensively. Find out more in this tip.

Share:

Benoit Marchal (bmarchal@pineapplesoft.com), Consultant, Pineapplesoft

Photo of Benoit MarchalBenoî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.



04 March 2004

Also available in Russian Japanese

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


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.


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.

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

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

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into XML on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=XML, SOA and web services
ArticleID=12383
ArticleTitle=Tip: SOAP 1.2 and the GET request
publish-date=03042004