1. Dec 17th, 2007

    Web Architectures and HTTP Mediocrity

    Michael Pittaro raises an interesting point:

    We often operate on the assumption that API’s matter as much as functionality. Although it’s always a pleasure to use a well designed API, in any language or any style, I’ve seen as many bad API examples as good ones. And it seems that in many cases, the API is secondary to the functionality – if someone needs the functionality, they will get around API hurdles.

    But is this really the case?

    SOAP as a concept is appealing to a lot of people, I think for much the same reason EJB was (still is?) appealing: it looks more complicated, and therefore must somehow be better.

    But SOAP as a concept is nothing more than XML/HTTP with an envelope thrown in for good measure, which means you can easily reduce from one to the other. The same service can do both, they just happen to be two flavors of the same API. And if you’re worried about tooling, don’t: WSDL 1.1 is equally uninspiring at either one.

    So it really doesn’t matter which one you choose, the functionality is all the same.

    But what if you build an API around the capabilities of REST? Say, for SimpleDB. What if queries returned links so you can traverse the graph? What if each resource had both XML and JSON representations? What if you could cache results and not bother processing items unless they changed? What if you could use ETag to update items, detecting and avoiding conflicts?

    All those are interesting features, but if you take a RESTful service like this and reduce it to SOAP, you lose them all. You’re not just swapping one interchangeable format for another, but trading one set of features for less.

    And the same thing is true if we design the whole thing around the WS-* stack. Not the conceptual SOAP, but the one mandated by the larger stack. We probably won’t use WS-Tx, but maybe asynchronous updating using WS-RM, or we could using WS-Eventing to listen to changes, or how about a standardized security framework?

    Here too, taking a WS-* service and reducing it to REST means losing some powerful features. In fact, SimpleDB offers a nice example in the way it uses WS-Sec/X.509 for SOAP and some horrible hack for signing non-SOAP requests.

    Basically, if you start with REST and WS-* as architectures to build your services around, they cease to be protocols you can abstract away. As architectures, each offers unique features you can take advantage of.

    It’s only when you’re building services around the architecture of mediocrity, that they blend together as two indistinguishable protocols. And it seems like there’s an equal number of people that believe XML/HTTP fundamentally needs SOAP, or that think SOAP without the envelope is REST. But then again, they might all be the very same person.

    Printable PDF | Posted by Assaf Filed in general 3 Comments »

    1. Dec 18th, 2007

      links for 2007-12-18 « Object neo = neo Object

      [...] Labnotes » Web Architectures and HTTP Mediocrity (tags: soa) [...]

    2. Jan 6th, 2008

      http://dvae.livejournal.com/

      That’s it. That’s exactly it. Horses for courses. Sometimes you need WS-Security and SAML, and sometimes you need ETags. Just because SOAP and REST are two different ways of sending messages that can be layered on HTTP does mean they work in the same market.

      So many times I’ve read ‘SOAP sucks’. And yes it does have it’s problems, but REST is not an alternative for many things.

      I have an app where we use WS-Security for encryption and message signing. It’s all done in the app server, for now. In a later release we can off load the processing onto off-the-shelf XML security appliances. You can’t make those kind of changes with a custom protocol, XMLRPC or REST. WS is the right fit in this case.

    3. May 26th, 2008

      bex

      “What if queries returned links so you can traverse the graph? What if each resource had both XML and JSON representations? What if you could cache results and not bother processing items unless they changed? What if you could use ETag to update items, detecting and avoiding conflicts?”

      SOAP can do all of that… just at the application layer, and not the protocol layer. Its no more difficult than creating a convention, then creating applications to conform to that convention.

      If you want neat-o REST stuff in SOAP, then just compile a list, and come up with the WS-REST specification.

    Your comment, here ⇓