Chris's Rants

Sunday, March 07, 2004

Doesn't GET it

I noticed this new IBM developerWorks article entitled: "Tip: SOAP 1.2 and the GET request" and was intrigued.

Unfortunately, the article simply perpetuates certain myths that I really wish would die.

First, the author writes:
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.
This is wrong on so many levels it scares me. SOAP was written by people who had the utmost respect for, and understanding of, HTTP. Sure, the SOAP1.1 (and I'm fairly certain that the author meant SOAP1.1 and not SOAP1.0) only defines a normative binding to HTTP POST, and maybe had the authors included a normative binding to GET things might be very different today. However, the whole point of SOAP was that it be extensible and that it could be mapped onto any transport protocol. No one had to wait around for the W3C XML Protocols WG to use SOAP in the context of other HTTP methods such as GET.

The article goes on to state:
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.
I'm sure that I don't know where in the SOAP1.1 spec (and again, it's pretty clear he means SOAP1.1) it says that anything must be a POST.

Further on it reads:
At the time of writing, Axis supports SOAP 1.1 only, but still implements a limited form of GET.
Huh? Really? Axis 1.1 supports SOAP1.2 last time I looked.

Finally, the author gets something right:
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.
I couldn't agree more. It is heartening to see others pick up on this. But, then the article finishes with this statement:
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.
Why wait? SOAP1.1 doesn't preclude the use of HTTP GET any more than it precludes a binding to FTP or WebSphereMQ.

If you have static content, all you need is to construct a SOAP envelope with the content and host it as a web resource using your favorite Web server. If the content is dynamic, use a Servlet or JSP to construct the SOAP envelope. This is NOT rocket science. It only becomes a little more complicated if you intend on leveraging some of the more advanced Web services features such as WS-Security. But think about it a bit. Do you need the likes of WS-Reliability for a GET? Nope, you can GET it as many times as you like because it is both safe and idempotent.

SOAP, while no longer an acronym for anything, is still simple. The trouble with simple is that there is a tendency of some to make it unnecessarily complicated.


Post a Comment

<< Home