Pragmatics?

Pragmatics
Someone recently asked me about how to handle an internal product debate around REST vs. SOAP.

In hopes I never have to address this debate again, here's a record of what I told them.

The following design decisions are orthogonal, even though people often conflate two or more of them:

1. Whether one uses SOAP or POX (plain-old-XML).
2. Whether or not one publishes an XML schema for their formats.
3. Whether or not one generates static language bindings from an XML schema.
4. The degree to which one relies on HTTP-specific features. That stated, screw with GET at your peril.
5. Whether one adopts a message-centric design approach or a resource-centric design approach.

Some of the decisions (specifically 5) are architectural and sometimes philosophical.

Some of the decisions (specifically 1-2) are simple business decisions that are determined by who your target audience is.

···
1. SOAP vs. REST, not SOAP vs. POX. Let's not overload the discussion with charged terms here.

···
2. REST folk (and not all REST folk are LAMP side) appreciate schemas as much as the SOAP crowd does. We just don't confuse the issue by putting method semantics into them.

···
3. REST folk assume that type is implied by validation, rather than forcing XML into explicit code reification.

···
4. GET works fine if the assumption is that you are not changing server state by doing so. That's been true since HTTP was standardized. Generally if you obey HTTP semantics, REST works just fine. If you don't, caveat emptor. (On a similar note, if you ARE obeying HTTP semantics, you shouldn't be sending XML via GET anyway).


5. The difference between a message-centric approach and a resource-centric approach is simply that in the first case you provide intent with the contents, while in the second you don't (the intent is implied by the target). They both contain a formulation of state.

I think one of the things that I find a little frustrating in this debate is this fundamentally arrogant attitude that SOAP-oriented developers have that REST programmers are incompetents who utilize poor programming practices rather than using the "enlightened" approach of SOAP/WSDL, instead of being competent programmers who have looked carefully at both approaches and realized that while both have their place (and I will readily admit that they do) the REST approach actually offers significant larger-scale benefits over SOAP in the areas that are relevant to them.

Don continues:

1. If you want a great experience for .NET/Java devs, you’ll typically publish schemas (through wsdl) and support SOAP.
2. If you want a great experience for LAMP folks, you’ll support POX messages and will provide a non-XSD description of your formats.
3. If you want to reach both audiences, you’ll do both #1 and #2.
4. If you want to reach both audiences before your competition does, you'll avoid indulging in religious debates and ship something.

1. I'd agree with #1.


2. I'd agree with #2, with the significant caveat that many REST people DO use XSD descriptions, not a few use Schematron or RelaxNG, and only a fool transmits XML that isn't validatable, even if it isn't validated. There is also a contingent of LAMP developers who are ardent SOAP/WSDL advocates, so be careful of generalizing.


3. I'd qualify #3 by saying, based upon discussions I've had with people at both Yahoo and Amazon, that SOAP tends to work best within a firewalled environment where you have stronger security contexts and can deal within internal servers as objective entities, while REST works far better outside of the firewall where you don't have those security contexts in place. In essence, you will have different audiences for #1 and #2 and should recognize that in your design.


4. As to #4, know your customers before you ship, and recognize that they will do EVERYTHING in their power to game the system to their advantage, so make sure before you DO ship something that you've done your due dilligence to mitigate that abuse. Internal services do not need to be as robust, in general, because internal rogues can be countered more easily.

Finally, I think there's a subtle point here (alluding to attitudes discussed earlier). While its easy to couch the arguments about approaches in religious terms (religious debates, evangelism, etc.), what is in question here is which approach is the best for the job at hand, not which approach is the more morally correct. This is an architectural decision, one based upon the needs and requirements of the customers, the competencies of the developers and the resources available to complete the job. If my requirements are to build an office building and the tools that you are offering are best suited to building cathedrals, I'd be hesitant to use those tools if ones that are more suited to office building construction are available.

SOAP and REST are not equivalent strategies, nor do they represent the "skilled" vs. the "unskilled" approach. Each has a specific domain where it has its strengths and should be used in that domain, just as each has its domain where it is weakest and should be carefully evaluated before being used in that other space. They are not even orthogonal - I think there are domains where you want to be able to offer both, where the two overlap, typically in those spaces where you are able to establish a "semi-trusted" perimeter. As application development moves into the realm of large-scale distributed applications where you likely do not own all of the nodes within the network, determining those boundaries and the appropriate tools will become one of the key differentiation points between the successful and the bankrupt.

Kurt Cagle is Director for New Technologies and Training with Mercurial Communications in Victoria, British Columbia, and is the author of multiple books on Web technologies, XML, SVG and AJAX. He is also the Chairman of the SVG Open 2006 Conference.

Kurt Cagle is an author and writer specializing in XML, Web 2, SVG, and blogging.

oreillynet.com Copyright © 2006 O'Reilly Media, Inc.