Search
Quick Links
Navigation
Popular Posts
Books By Bex
User login
Recent comments
- RE: The Origin Of Bex
3 hours 1 min ago - RE: The Origin Of Bex
5 hours 54 min ago - retrocasualty
11 hours 44 min ago - Yeah, but the government
22 hours 41 min ago - "I'm Feeling Lucky" is also a security hole...
6 days 1 hour ago - Old news
6 days 21 hours ago - Re: Bacon Vodka
1 week 18 hours ago - Bacon Vodka
1 week 21 hours ago - Re: wtf
1 week 2 days ago - wtf
1 week 2 days ago
Damien Katz Come Out Swinging Against REST
I'm never been a huge fan of REST... Its advocates bash SOAP for being too complex -- which I agree with -- but then they make all kinds of bizarre claims to shame people into dropping SOAP entirely. I've heard my own fair share of nonsensical pro-REST rants, including:
- The web is REST, therefore REST is as awesome as the web!
- HTTP POST is evil, but GET, PUT, HEAD and DELETE are awesome!
- Create/Read/Update/Delete is all you ever need!
- URL parameters before the "?" are okie kosher, but after the "?" they are evil!
- SOAP's superior security model is irrelevant; HTTPS and basic auth is all people need!
- Simplifying SOAP is not an option! We must scrap the whole thing!
- HTTP is perfect! PERFECT I SAY! There is never a need to tunnel data through it!
Personally, I'm a fan of using HTTP POST with SOAP formatted data in order to alter resources (create, edit, delete, move). If all you want is to read data, then your system should support SOAP based responses to a standard HTTP GET request on a URL. It solves most of the complexity problems that people complain about, without ditching your SOAP infrastructure. Also, it allows you to use the exact same API for both your web interface, and your developer API.
Oddly enough, this is exactly how the Stellent server works ;-)
Anyway, recently tech geek Damien Katz -- the inventor of the RESTful database CouchDB -- has recently come out swinging against the pro-REST non-sense:
Sam Ruby claims Katz is fighting straw men... but I'm not sure Sam's argument holds water. Katz is simply calling bullshit on the #1 claim of most REST fanboys. Sam can't have it both ways: he can't benefit from his rabid fan base, and not publicly shame them for their falsehoods. If Katz is fighting a straw man, then Ruby should make it clear to his minions that the #1 claim they use to push REST is totally false.
Then... THEN we can see if the other benefits justify scrapping SOAP... or using REST instead of something with a less fanatical fan base.
Comments
REST Dogmatism
I agree, Bex. The REST vs. SOAP debate has simply devolved into the latest religious war in computing. Ultimately, it's about using the right tool for the job, period.
Having worked with both REST- and SOAP-based web services, I personally prefer the REST style. It's what we use at Infovark, and I think it was the right decision. Since we developed our codebase from scratch, the guidelines and norms of REST-style architectures informed the design of our application. It imposed discipline and simplicity that forced us to abandon overly complicated business rules. Simplicity is a desirable goal for any framework, and as Douglas Crockford recently pointed out, simplicity is not something that can be added later.
However, if I already had a complex API and wanted to retrofit a web service to it, I'd pick SOAP. It's far more comprehensive. Its ability to serialize object data directly to the wire makes it a much better choice. SOAP also works right now; the REST style won't truly come into its own until all web browsers support PUT and DELETE. Even REST die-hards have to admit that they, too, are tunneling through POST until HTML 5 makes support for those headers ubiquitous.
Is it really about REST vs SOAP? I don't think so...
Hmm... I think this is a little bit misguided. REST vs SOAP is more like comparing apples and oranges. After all, SOAP is just a way of sending XML over http (for that matter it doesn't have to be http). I believe the argument is about complexity of WS* stack. Unlike minimalistic approach of REST following WS* stack puts too many expectations on both service provider and service consumer thus working against concept of loose coupling. In this sense, Stellent ... oops Oracle UCM cannot claim to support web services as it doesn't implement most of WS* specifications. But does it have to?
In addition, REST provides nice abstraction layer as it is based on idea of manipulating resources directly instead of using proprietary WSDL. For example, that is exactly what Oracle UCM web services do - lock clients into details of Content Server commands. RESTfull API, on the other hand, would couple client with the content taxonomy only - a pretty significant improvement.
still dealing with an API...
When dealing with a simple API, you can't really say SOAP is more complex than REST... unless all you are dealing with is a web interface to a file system, the REST API will need to be as well documented as any SOAP API... perhaps even more, because of their tendency to focus on resources and not services. Since taxonomies don't really scale to the enterprise, you'll need multiple taxonomies and multiple metadata models to browse for (and search for) content. So, a REST API to a repository of any real complexity would be equally guilty of "locking clients into details."
Like you said, you don't need all of the WS-* stack... in fact, there is a great deal of evidence that most of the WS-* stack was made intentionally confusing to discourage people from using simple tools:
http://www.regdeveloper.co.uk/2006/04/29/oreilly_amazon/
I disagree that you have to implement all of the WS-* stack to claim you support "web services." I believe REST is also a web service, as is a plain 'ol HTTP GET that returns HTML.
Little SOAP and you are ok..
What amuses me is the fact that despite IBM, Microsoft and the rest of the guys are pushing SOAP, REST keeps on taking care of business. With huge number of WS-* (have they made WS-bureaucracy yet?) standards this is a case of, have the same stack on both sides and perhaps you are ok. So pick the right technology for the job and do it. If for some reason SOAP is the right job, I recommend using as little of it as possible.
Now for full disclosure, after fighting IBM WS-* and MS WS-* interoperability for a long time. I am now completely at REST but have a much more momentum.
I like ReST, but the inevitable dogmatism irks me...
SOAP is nice because you can pretty much have anything talk to anything, and it doesn't take that much effort to interoperate. That is, unless you want the WS-* stack to do everything for you...
Now... when it comes to ReST, when you start making necessary sacrifices to make it easier/faster/more robust when two systems to communicate, you'll get bogged down in flame wars about how you're "not really ReST-ful." And its about completely absurd nuances that make limited sense when you're using hypertext... but not when you're trying to integrate an event-driven model, a universal API, or messaging.
I think we need a new word... because I've never seen a "ReST" API that would both satisfy the purists, AND be as universally useful as SOAP.
Post new comment