REST not for tubes, but still suitable for UI
I pondered if to participate or not but what the hell… Here’s my contribution (if a bit late but so not) to the discussion about technologies of teh internetz, especially SOAP and REST. The whole issue is less relevant for an average Java EE programmer, as the framework provides ‘equal’ support for both of them — it’s merely a matter of referring to either HTTPBinding or SOAPBinding constants in the code; or
<http:binding .../> if I happen to be playing with dem wisdls. This let’s you focus on writing the actual business logix; I don’t know when the restafarians GTD while they’re arguing over some fr*cking transports. In (some) ‘real world’ systems the messages1 are constructed and handled in a normalized form and serialized not until by the binding component, was it SOAP or REST (or SMTP, XMPP or whatever.)
SOAP is handy as it’s more structural compared to REST. There are standard ways to represent for example destination address, sender identity, or signature independently of the transport layer. This makes it more straightforward to proxy the messages through different types of pipes. REST relies purely on HTTP mechanisms on representing metadata, and although less complexity is a good thing by itself, it limits the metadata to be expressible in the HTTP header (1,2,3,4). For example, if we would sport XMPP as a transport protocol, I guess SOAP Over XMPP would be a lot simpler compared to some proprietary HTTP binding style. Of course we could normalize a REST request and then create a corresponding SOAP message, but this requires extra mapping.
At some point some de facto standards must emerge also for REST to represent those most common artifacts like addressingÜ, identity & federation. And why not the restafarians could just glance over the WS-Addressing, WS-Federation and WS-Security specifications and pick the useful parts while ignoring the excess scheisse? Little humbleness pays in the long run. Btw., if you don’t need the WS-Hairball, there’s no use bothering oneself with those overly academic specs — they’re just tools to be used when needed. (IMHO it’s not utterly bright to diss SOAP by the plain existence of some fussy specifications.) Oh man, I’d be so glad if eBay would provide a standard federation mechanism instead of the proprietary solution.
Of course it pays a long way to educate oneself on these things, but the environment is readily set in many cases; thus some worker may have little motivation to listen about these things. They just pick up the libraries on demand basis. (Disclaimer: I’m not one of the entities who cultivate such attitude.)
And it’s no wonder Google dropped the SOAP interface as it doesn’t provide any end-user attention (ie. ad business) for them; unless they’d start monetizing the search results directly as in selling search result slots. In other words, it didn’t support their core business. (I noted about this ‘core business’ / monetization issue before.) At least with AJAX you know there’s a browser on the other end, thus offering a suitable platform for AdSense.
But yay, as a Java programmer, it’s nice to be able to talk with both parties, the enterprisey and the REST of the world. LOGO HEART Java.
Ha, I managed to write a post for December. :) Successful 2007 for everyone!