North and South
David Chapelle writes that
To anybody who’s paying attention and who’s not a hopeless partisan, the war between REST and WS-* is over. The war ended in a truce rather than crushing victory for one side–it’s Korea, not World War II. The now-obvious truth is that both technologies have value, and both will be used going forward.
That’s a nice analogy. Take it one step further though. WS-* is North Korea and REST is South Korea. While REST will go on to become an economic powerhouse with steadily increasing standards of living for all its citizens, WS-* is doomed to sixty+ years of starvation, poverty, tyranny, and defections until it eventually collapses from its own fundamental inadequacies and is absorbed into the more sensible policies of its neighbor to the South.
The analogy isn’t as silly as it sounds either. North Korean/Soviet style “communism” fails because it believes massive central planning works better than the individual decisions of millions of economic actors. WS-* fails because it believes massive central planning works better than the individual decisions of millions of web sites. It’s no coincidence that the WS-* community constantly churns out volume after volume of specification and one tool after another. The WS-* community really believes that developers are too stupid to be allowed to manage themselves. Developers have to be told what to do and kept from getting their grubby little hands all over the network protocols because they can’t be trusted to make the right choices.
By contrast you don’t see a lot of complicated REST frameworks or specifications. You could read all the relevant REST specifications in a slow afternoon (mostly the HTTP spec and a couple of subsidiary RFCs, plus XML and Namespaces in XML. Maybe Atom syntax and Atom-pub too if you feel ambitious.). REST/HTTP sets up a simple economic system based on a few clear rules, and then pretty much gets out of the way to let people do their own thing. It doesn’t even get too upset when people break the rules, and start tunneling everything through POST or deleting items with GET. The main people harmed by such bad decisions will be the sites themselves, and they will be dealt with by the RESTful market.
July 6th, 2007 at 5:40 am
Ye gods I love that analogy!!! 😉
July 6th, 2007 at 6:56 am
(First comment seems like it might have been lost in the spam filter, so trying again…)
What is “WS-*”?
July 6th, 2007 at 11:46 am
[…] Eliotte nails WS-* web services. There has been constant attempts from WS-* web service proponents to claim that there was one big tool shed and that people could pick their favorite type of web services. The hidden message is that there are various options, that WS-* might be best for serious work whereas REST web services are better for the little guy. In other words, WS-* didn’t fail, we just have different solutions to different problems. It is not so. WS-* is North Korea and REST is South Korea. While REST will go on to become an economic powerhouse with steadily increasing standards of living for all its citizens, WS-* is doomed to sixty years of starvation, poverty, tyranny, and defections until it eventually collapses from its own fundamental inadequacies and is absorbed into the more sensible policies of its neighbor to the South. […]
July 7th, 2007 at 3:29 am
I agree with David Chapell. In his blog he wrote, “The now-obvious truth is that both technologies have value, and both will be used going forward.” Additionally, he wrote, “A RESTful approach is a natural for data-oriented applications that focus on create/read/update/delete scenarios. Lots and lots of apps fit this model, especially on the public Internet. A solution based on WS-* makes more sense for service/method-oriented applications, especially those that need more advanced behaviors such as transactions and more-than-basic security. (Doubt this last point? Look up “Security” in the index of the Richardson/Ruby book: Exactly one page number is listed.)”
Ethan Cerami wrote in his book titled “Web Services Essentials”, that a web service should be self-describing and that a web service should be discoverable. The REST crowd has never been able to tell me how REST meets these two criteria, let alone tell me how REST can handle secure transactions with multiple partners.
The idea of web services back in 2002 was an automated, application-centric web, as described in Ethan Cerami’s book. I know that REST is great for data centric applications not requiring high level security or transactions. I know all too well, that the implementation of web services has been a disaster, but I must agree with David Chappell, that WS-* and REST are two solutions to two different problems and that depending on the problem at hand, REST or WS-* can be the best solution.
July 7th, 2007 at 4:23 am
James,
There is discoverability and describability for RESTful applications. It’s called “HTML”. In reality, that’s the only kind of discoverability and describability WS-* has too. All the WSDL and UDDI fantasies about systems that magically self-configure themselves without human intervention was nothing more than a pipe dream. It never worked and I very much doubt it ever will.
As to service/method-oriented applications, that’s just a way of saying you’re designing a non-RESTful architecture. REST quite deliberately is not method-oriented. That’s the point. There are only four verbs, and that’s all you need for most applications. To design RESTfully, you focus on the resources, not the services. That is, the nouns, not the verbs. If you look at the functionality the services and methods are supposed to provide, rather than the services and methods themselves, REST can almost always handle the application quite nicely.
Finally, REST most certainly can handle transactions and security. Security is built into HTTP, and you can throw in XML digital encryption if that helps too. If you need something more or different, it’s not hard to add. RESTafarians usually don’t bother with transactions because most applications don’t need them. Usually all information needed to complete an operation can be sent as one request, but if not transactions themselves can be modeled. See section 8.8.4 of RESTful Web Services for one approach.
July 8th, 2007 at 8:06 am
James:
Well, that’s certainly a good way of saying that REST doesn’t do what Ethan Cerami wants, and by extension, what you want. But with respect to web services, it’s “begging the question:” you’re defining web services in Ethan’s terms. Nothing wrong with that, but why should we assume that people implementing REST are trying to accomplishing Ethan’s goals? The point of Rusty’s analogy with Communism is that they REST implementors are trying to accomplish their own goals, and it works.
I see your analogy as being similar to an apparatchik complaining that nobody has ever been able to explain to him how small businesses will be able to create the reports and paperwork that the state-run organizations generate. No, they don’t, but the paperwork and reports aren’t the goal, they are tools for achieving a goal, tools that have been discredited in seventy years of experience with them.
Turning back to REST, the point is that many, many applications work just fine with four verbs and a resource orientation. We can sit around all day finding edge cases that require extra layers of abstraction over REST, but to impose Central Planning for the sake of edge cases is a net loss over giving people freedom through simpler protocols.
July 8th, 2007 at 8:27 am
North Korean/Soviet style “communism†fails because it believes massive central planning works better than the individual decisions of millions of economic actors.
That or all the guns waved in people’s faces but I digress.
July 9th, 2007 at 4:02 am
Elliotte,
The ability to put ?wsdl behind the url to get the interface specs is really valuable to me. We use multiple services managed by third parties and we’ve regularly seen unexpected interface changes. Examining the wsdl allows us to quickly point out the issue to the vendor and (get them to) release a fix. Note that this ability is ‘free’. You can easily turn a plain old Java object into a web service and the wsdl is generated automagically. In contrast, requiring each vendor to maintain a HTML page in a standard format sounds very North Korean (and similarly untrustworthy). Note that this use of wsdl has nothing to do with self-configuration, which I agree is useless.
I also would like to point out that the flaw in communism is not that there are centralized standards. Centralized allocation and mandatory pricing means that there is little incentive to innovate/work hard and that the available production capacity is used very inefficiently. In contrast, moderate standardization is a boon to the economy. Standards such as unified currency, health & safety codes, a standard metric system, food quality standards and accounting laws are a boon to the capitalist system, since they increase the transparancy of the market. The most price-efficient markets tend to be the most standardized. Of course, the different needs of consumers often result in more complex, less efficient marketplaces. So in conclusion, the comparison to North Korea is faulty since you are not told what services to create, only how. Even there, most of the how is optional.
PS. I certainly don’t feel that WS-* is perfect, but I don’t see how it’s much worse (or better) than REST for most applications.
July 9th, 2007 at 8:38 am
“The ability to put ?wsdl behind the url to get the interface specs is really valuable to me” says it all. That is a RESTful convention, unfortunately it doesn’t fit into SOAP land where the endpoint may be on any transport, MQ, MSMQ, Sonic, XMPP, JMS, email, etc, etc.
I suggest you read about WS-MetaDataExchange, central to how a lot of people think about WS-*. The defacto, RESTful ?wsdl convention is dead!
July 10th, 2007 at 1:51 am
Thanks, Elliotte, for setting me straight on how to handle REST security and pointing me to an explanation of one method of handling transactions with REST. I believe, as you do, that looking at the functionality the services and methods are supposed to provide, rather than the services and methods themselves, REST can almost always handle the application quite nicely. I also agree with Reg Braithwaite when he states “REST implementors are trying to accomplish their own goals, and it works.”
In spite of this, I’m not convinced that WS-* is dead. Consider a large organization. If the organization decides to base the exchange of data within the organization on REST, won’t the organization be programming many, many similar applications and programming interfaces between applications over and over again? If a large organization decides to base the exchange of data within the organization on WS-* on top of a service oriented architecture, isn’t it much easier to reuse services in many applications?
Ever hear of BPEL, Business Process Execution Language, known as the language for service oriented architecture? BPEL is an XML language for describing technical business processes. BPEL doesn’t produce applications as we know them normally today, but combines existing resources to fulfill the needs of a business process. BPEL is looking like it will be the key function for automating business processes. It orchestrates available services inside and outside an organization into a series of technical processes to solve business needs. BPEL allows for efficient reuse of services in multiple “applications”. Anything whose interface can be described using WSDL is a service available for use by BPEL. Theoretically, the Open Source Apache Web Service Invocation Framework (WSIF), which basically allows any code fragment to be described using WSDL and allows any code fragment to look like a web service, could be used to integrate REST based applications into BPEL. Maybe I’m too optimistic, but I believe that WSDL and UDDI, or things similar to WSDL and UDDI, may indeed work some day. On a small scale they’re being used today in large organizations that are moving toward service oriented architectures. Wouldn’t use of a stack consisting of BPEL, on top of web services, sitting on a service oriented base eliminate programming many, many similar applications and programming interfaces between applications over and over again?
July 10th, 2007 at 4:31 am
Paul,
I don’t see ?wsdl going anywhere. Even if it does go away, it doesn’t matter, since WS-MetaDataExchange supports the same functionality. It’s also not significant that WS-MetaDataExchange is not RESTful like ?wsdl, since SOAP itself is not build to be RESTful. The essence of SOAP is that the message defines the request, while the URL is the central part of REST. There are advantages and disadvantages to both approaches, but it’s rather silly to blame WS-* for wanting to replace the very unSOAPy ?wsdl with something more consistent.
Complaining that parts of WS-* are not REST is like bitching that parts of the North Pole are too cold.
July 11th, 2007 at 8:59 am
Complaining that parts of WS-* are not REST is like bitching that parts of the North Pole are too cold.
Good analogy. If someone tells me to go live on the North Pole, I am sure as hell going to complain that it is too cold.
July 11th, 2007 at 10:51 am
[…] Update 7/11/2007 (via DonR): The REST vs. WS-* war analogy deepens, thanks to Elliotte. WS-* is North Korea, and REST is South Korea. […]
July 11th, 2007 at 11:16 pm
?wsdl is not RESTful. Per REST the URI is opaque to anyone but the issuer.
The RESTful way to do this would be with an Internet-standard data format.
July 12th, 2007 at 3:55 am
[…] Rusty Harold with an interesting commentary on the REST vs WS-* […]
July 12th, 2007 at 4:25 am
Lucas Gonze: The RESTful way to do this would be with an Internet-standard data format.
Care to elaborate on that? That smells suspiciously like mandating the use of some serialisation of RDF for everything.
July 12th, 2007 at 8:17 am
The platform politics rage on. Meanwhile, an uncounted number of us sit happily grinding out applications that include WS web services supported by a platform that even where clunky in local hands-on-keyboard terms works well, results in a professional looking and performant application, and keeps the cash flowing in our direction. Why? That is what the requirements call out and the last thing we want to do is roll back OASIS.
Rage on. There is too much work to do to spend time worried about REST or WS. I consider that a good thing.
July 12th, 2007 at 9:19 am
Keith: an RDF serialization would be a legal way to do this. More likely, an HTML form would do the job.
The gist of the argument is that protocols are supposed to be developed using document formats, and optimally using standardized document formats with formal media type registrations.
URI structure is undefined in REST, except to the extent that document formats like HTML forms can be used to document query arguments. It’s not illegal for humans to recognize and take advantage of editable patterns in URI structure, but it is illegal for programmers to develop new protocols which require third parties to structure URIs in a particular way.
The way it’s supposed to work is that the server emits a form which the client then fills in. The way it’s not supposed to work is that the server publishes a document on URI structure on that site which third parties then have to adhere to.
The formal name of this idea is “hypermedia as engine of application state.”
July 12th, 2007 at 6:12 pm
Ahhh the wonderful “all developers know what they are doing” and “trust the developers mantra” and the standard “REST is simpler than WS-*”.
Taking the first two first. I don’t trust developers, I am a developer and an architect and a manager and I know that all developers are not created equal. To pretend that every developer is a James Gosling when there are people who can’t even write a semaphore is just plain silly.
On the second point REST is not simple, sure you can read the specifications (if you are of an extremely technical bent, VB developers? I think not) but in terms of implementation (if done properly and not just POX) there are quite a few complexities in REST that make it hard to do well, and easy to do POX while pretending to REST. REST is also not simple because it has no security model of note, it has no answer to message reliability. It is true that systems become simpler if you ignore reliability and security, but I’m not overly sure that this is a good thing.
REST v WS-* is more like two people arguing at MIT whether North Dakota or South Dakota has the best university. Its a pointless.
July 12th, 2007 at 8:30 pm
The Korean war did not end in truce. In fact, it never ended:
July 13th, 2007 at 12:32 am
[…] But the little guys shouldn’t be trusted with headers. They’d poke their eyes out. Or, as Elliotte Rusty Harold recently wrote (on a related topic, namely WS-* versus REST), “developers have to be told what to do and […]
July 13th, 2007 at 3:57 am
Convergence?
Indeed.
WS-* and the misunderstanding of XML-RPC as Representational State Transfer are both going down the drain.
The new kid on the block is named JSON and it is quickly replacing XML as *the* object serialization protocol for network peers. Why? Because it *is* an object notation not some misapplied text markup language, because it suites dynamic languages and because it is at least one order of magnitude less verbose and faster to handle than SOAP.
Google already dropped support for WS-*, others will sooner or later follow the leadership.
Of course the “enterprise” dummies will cling on their BS-* along the lines of “Why make it simple and fast when you can make it infuckingcredibly complicated and slow?”
July 14th, 2007 at 3:53 pm
Ted Neward has a follow up:
http://blogs.tedneward.com/2007/07/14/The+Korean+Conflict+And+Why+SOAP+And+REST+Were+Never+A+Quotwarquot.aspx
July 15th, 2007 at 4:23 am
[…] Elliotte Rusty Harold extends David’s ‘Korean War’ metaphor, to suggest that “WS-* is North Korea and […]
July 16th, 2007 at 9:08 am
Gee, gotta love religious wars, especially when the religions are still evolving….
But seriously folks, something simpler than either approach is needed. I’m a developer/part-time manager being bombarded by 100+ methods of programming “best practices,” languages, IDEs, COTS/Open Source products, not to mention distributed processing protocols. Do I really have the time to be intelligent on any of these subjects? No. I also have upper-level managers (who can’t be bothered to understand it themselves) asking which way to go. Can I give them a good answer? No. So what do we end up choosing? The protocol (or whatever) which is currently “the most supported.” Unfortunately that usually means “the one which has the approval of some big organization (OMG, W3C, etc.) and has the most transparent multi-vendor support.” So, when you get right down to decision time, which one gets chosen? In reality, I simply don’t care as long as I can use it until I get forced into using something else. Sorry to say this, but (for me) the “war” is over and has been for some time. Yes, I may be implementing something inefficiently, but in the real world, time seems to be more important than efficiency.
So now I’ll ask my question: What ever happened to creating a single, simple API (not like Java 5’s 3200+ classes with at least 3 different ways to do I/O) that can be used forever and in any language, while the protocols are changed “behind the scenes” to make everything more efficient? That way, the operating system and network folks can play with the hardware and protocols to their hearts desire while leaving something stable for the rest of us to program to….
August 31st, 2007 at 3:18 pm
There is water, there is milk and by god we’ll drink both depending on the situation.
September 3rd, 2007 at 9:59 am
[…] took up Chapelle’s comparison of the REST/WS* debates to the Korean conflict, writing in North and South, that the analogy is quite apt: Take it one step further though. WS-* is North Korea and REST is […]
September 25th, 2007 at 1:44 pm
Nice comparison. Difficult not to think of the 1984 http://www.youtube.com/watch?v=OYecfV3ubP8 ad… Especially seeing the involvement of IBM in the WS-* stack.
August 26th, 2008 at 11:08 am
[…] them on my sleeve, and this analogy really cracked me up… some interesting comments as well. The Cafes » North and South : The analogy isn’t as silly as it sounds either. North Korean/Soviet style “communism” fails […]
November 21st, 2008 at 4:42 am
I note with amusement that Elliotte Rusty Harold doesn’t serve up his sassy little anti-Macintosh website anymore. He pretends now that it never existed. Many of us still remember and have had dealings with this tool. He thinks he is god’s (lower case intentional) to the computing world, but actually he is just another wanker in the computing cloud. Funniest line from his webpage: “As well as my popular books and writings on the web…” Uh, yeah Elliotte you’re just Mr. Popular, aren’t you. Do something about the hair, dude… you’re looking more and more like Bozo the Clown everyday.
May 9th, 2010 at 5:30 am
[…] them on my sleeve, and this analogy really cracked me up… some interesting comments as well. The Cafes » North and South : The analogy isn’t as silly as it sounds either. North Korean/Soviet style “communism” fails […]