"marketecture"

I came across this term here, and found it mildly amusing. or maybe more than that, amusing enough to make a blog post about it...and you can see I haven't been doing much of that recently. even though I'm an SOA and Web Services fan-boy, I enjoy very much when people put a big wet blanket on the ideas because it keeps us zealots honest and grounded to reality.

Adam Bosworth from Google was probably the first to destabilize my vision of a global information marketplace using only SOAP messages. he talked about REST at the Web 2.0 conference in a discussion panel titled "The Platform Revolution," and what he said really stuck with me. I don't have any quotes or minutes to look up, so listen to the entire discussion (~1 hr.).

essentially, Bosworth asserted that it is human imperfections that encourage innovation and creativity. and he quickly summarized what I'm about to say in more length...

how this relates to REST vs. SOAP is that SOAP is designed to be The Solution - created to faciliate all communication needs for every situation and in such a way as to be completely and totally independed of underlying transport, extensible beyond imagination, etc. however, that also means that SOAP is very complicated. in order to understand the 'why' of SOAP, you have to at least dabble into a large number of example scenarios of usage of each of the features of SOAP before you appreciate the inclusion of all the complexity. there are (and will be) some good books about it, and I've been thru some. I think I now understand most of the "why" of the complexity of SOAP.

but as I've been learning, knowing the "why" of something is hardly sufficient, even less so when that something is to be used for solving real-world problems. one problem might be the need for cross-communication between system X and system Y by date D. in the purely theoretical world, absent of the date D parameter, you choose SOAP and work until you've got that loosely coupled, platform-independent, extensible solution. but since date D is important in the real world, the below example shows that perfect elegance is not always the best option, and is sometimes no option at all.

I've also done work with REST web services. and I must say that the simplicity and ease of REST is no small convenience. specifically, we consume our current UPS web serices via REST, and we will likely be expanding the number of services we implement because it was only a matter of a few hours from start to finish on implementation. by contrast, when we explored replacing our in-house, expensively maintained, sales-tax tracking system with a StrikeIron web service, we initially had only the WSDL, and therefore SOAP, to work with.

to the discredit of both ColdFusion MX and PHP 5, we found that neither includes built-in, functional support for inclusion of SOAP Headers. In the case of PHP 5, it mangled the XML markup in the header by invoking an http_encode type transformation on it, and it also prematurely closed the root element of the SOAP Body, in addition to erroneously skipping over the first of the items in the parameter array. ColdFusion MX has no support for SOAP Headers, until you download and install an update. And even then, we never were able to work with it, because it would just outright fail to parse the WSDL correctly.

however, to the credit of REST, we were able to more simply and easily work with an RPC-type interface by issuing simple HTTP GET (included in both languages) with the two arguments and receive our XML response. bliss.

it can be reasonably assumed that these particular faults will be corrected in future versions of the languages. indeed, it's easy to think back to the days when HTTP was the brand new, complicated transport that had numerous problems and bugs as people were still learning how to use it. but it doesn't change the fact of the matter that as of right now, before date D, REST lets us do what we need.

bringing it back to the idea of human imperfections...

most reasonable system analysts will say that the REST systems we have implemented are imperfect, and they're correct. but, because it is working right now, it enables methods of communication (however "clunky") that foster innovation in other places. ie, the business users of our system who now have more tools available to them.

now, I'm hardly an advocate of inelegance, and I'd love to eventually replace our REST interfaces with SOAP and WSDL interfaces, along with lots of other changes to our current systems. but as an interim measure, or a quick-and-easy solution, take a REST.